Cryptocurrency historical datasets from January 2012 (if available) to October 2021 were obtained and integrated from various sources and Application Programming Interfaces (APIs) including Yahoo Finance, Cryptodownload, CoinMarketCap, various Kaggle datasets, and multiple APIs. While these datasets used various formats of time (e.g., minutes, hours, days), in order to integrate the datasets days format was used for in this research study. The integrated cryptocurrency historical datasets for 80 cryptocurrencies including but not limited to Bitcoin (BTC), Ethereum (ETH), Binance Coin (BNB), Cardano (ADA), Tether (USDT), Ripple (XRP), Solana (SOL), Polkadot (DOT), USD Coin (USDC), Dogecoin (DOGE), Tron (TRX), Bitcoin Cash (BCH), Litecoin (LTC), EOS (EOS), Cosmos (ATOM), Stellar (XLM), Wrapped Bitcoin (WBTC), Uniswap (UNI), Terra (LUNA), SHIBA INU (SHIB), and 60 more cryptocurrencies were uploaded in this online Mendeley data repository. Although the primary attribute of including the mentioned cryptocurrencies was the Market Capitalization, a subject matter expert i.e., a professional trader has also guided the initial selection of the cryptocurrencies by analyzing various indicators such as Relative Strength Index (RSI), Moving Average Convergence/Divergence (MACD), MYC Signals, Bollinger Bands, Fibonacci Retracement, Stochastic Oscillator and Ichimoku Cloud. The primary features of this dataset that were used as the decision-making criteria of the CLUS-MCDA II approach are Timestamps, Open, High, Low, Closed, Volume (Currency), % Change (7 days and 24 hours), Market Cap and Weighted Price values. The available excel and CSV files in this data set are just part of the integrated data and other databases, datasets and API References that was used in this study are as follows: [1] https://finance.yahoo.com/ [2] https://coinmarketcap.com/historical/ [3] https://cryptodatadownload.com/ [4] https://kaggle.com/philmohun/cryptocurrency-financial-data [5] https://kaggle.com/deepshah16/meme-cryptocurrency-historical-data [6] https://kaggle.com/sudalairajkumar/cryptocurrencypricehistory [7] https://min-api.cryptocompare.com/data/price?fsym=BTC&tsyms=USD [8] https://min-api.cryptocompare.com/ [9] https://p.nomics.com/cryptocurrency-bitcoin-api [10] https://www.coinapi.io/ [11] https://www.coingecko.com/en/api [12] https://cryptowat.ch/ [13] https://www.alphavantage.co/ This dataset is part of the CLUS-MCDA (Cluster analysis for improving Multiple Criteria Decision Analysis) and CLUS-MCDAII Project: https://aimaghsoodi.github.io/CLUSMCDA-R-Package/ https://github.com/Aimaghsoodi/CLUS-MCDA-II https://github.com/azadkavian/CLUS-MCDA

Crypto Fear and Greed Index

Each day, the website https://alternative.me/crypto/fear-and-greed-index/ publishes this index based on analysis of emotions and sentiments from different sources crunched into one simple number: The Fear & Greed Index for Bitcoin and other large cryptocurrencies.

Why Measure Fear and Greed?

The crypto market behaviour is very emotional. People tend to get greedy when the market is rising which results in FOMO (Fear of missing out). Also, people often sell their coins in irrational reaction of seeing red numbers. With our Fear and Greed Index, we try to save you from your own emotional overreactions. There are two simple assumptions:

• Extreme fear can be a sign that investors are too worried. That could be a buying opportunity.
• When Investors are getting too greedy, that means the market is due for a correction.

Therefore, we analyze the current sentiment of the Bitcoin market and crunch the numbers into a simple meter from 0 to 100. Zero means "Extreme Fear", while 100 means "Extreme Greed". See below for further information on our data sources.

Data Sources

We are gathering data from the five following sources. Each data point is valued the same as the day before in order to visualize a meaningful progress in sentiment change of the crypto market.

First of all, the current index is for bitcoin only (we offer separate indices for large alt coins soon), because a big part of it is the volatility of the coin price.

But let’s list all the different factors we’re including in the current index:

Volatility (25 %)

We’re measuring the current volatility and max. drawdowns of bitcoin and compare it with the corresponding average values of the last 30 days and 90 days. We argue that an unusual rise in volatility is a sign of a fearful market.

Market Momentum/Volume (25%)

Also, we’re measuring the current volume and market momentum (again in comparison with the last 30/90 day average values) and put those two values together. Generally, when we see high buying volumes in a positive market on a daily basis, we conclude that the market acts overly greedy / too bullish.

Social Media (15%)

While our reddit sentiment analysis is still not in the live index (we’re still experimenting some market-related key words in the text processing algorithm), our twitter analysis is running. There, we gather and count posts on various hashtags for each coin (publicly, we show only those for Bitcoin) and check how fast and how many interactions they receive in certain time frames). A unusual high interaction rate results in a grown public interest in the coin and in our eyes, corresponds to a greedy market behaviour.

Surveys (15%) currently paused

Together with strawpoll.com (disclaimer: we own this site, too), quite a large public polling platform, we’re conducting weekly crypto polls and ask people how they see the market. Usually, we’re seeing 2,000 - 3,000 votes on each poll, so we do get a picture of the sentiment of a group of crypto investors. We don’t give those results too much attention, but it was quite useful in the beginning of our studies. You can see some recent results here.

Dominance (10%)

The dominance of a coin resembles the market cap share of the whole crypto market. Especially for Bitcoin, we think that a rise in Bitcoin dominance is caused by a fear of (and thus a reduction of) too speculative alt-coin investments, since Bitcoin is becoming more and more the safe haven of crypto. On the other side, when Bitcoin dominance shrinks, people are getting more greedy by investing in more risky alt-coins, dreaming of their chance in next big bull run. Anyhow, analyzing the dominance for a coin other than Bitcoin, you could argue the other way round, since more interest in an alt-coin may conclude a bullish/greedy behaviour for that specific coin.

Trends (10%)

We pull Google Trends data for various Bitcoin related search queries and crunch those numbers, especially the change of search volumes as well as recommended other currently popular searches. For example, if you check Google Trends for "Bitcoin", you can’t get much information from the search volume. But currently, you can see that there is currently a +1,550% rise of the query „bitcoin price manipulation“ in the box of related search queries (as of 05/29/2018). This is clearly a sign of fear in the market, and we use that for our index.

There's a story behind every dataset and here's your opportunity to share yours.

Copyright disclaimer

This dataset is produced and maintained by the administrators of https://alternative.me/crypto/fear-and-greed-index/.

This published version is an unofficial copy of their data, which can be also collected using their API (e.g., GET https://api.alternative.me/fng/?limit=10&format=csv&date_format=us).

Twelve Data is a technology-driven company that provides financial market data, financial tools, and dedicated solutions. Large audiences - from individuals to financial institutions - use our products to stay ahead of the competition and success.

At Twelve Data we feel responsible for where the markets are going and how people are able to explore them. Coming from different technological backgrounds, we see how the world is lacking the unique and simple place where financial data can be accessed by anyone, at any time. This is what distinguishes us from others, we do not only supply the financial data but instead, we want you to benefit from it, by using the convenient format, tools, and special solutions.

We believe that the human factor is still a very important aspect of our work and therefore our ethics guides us on how to treat people, with convenient and understandable resources. This includes world-class documentation, human support, and dedicated solutions.

I am a new developer and I would greatly appreciate your support. If you find this dataset helpful, please consider giving it an upvote!

Key Features:

Complete 1d Data: Raw 1d historical data from multiple exchanges, covering the entire trading history of BTCUSD available through their API endpoints. This dataset is updated daily to ensure up-to-date coverage.

Combined Index Dataset: A unique feature of this dataset is the combined index, which is derived by averaging all other datasets into one, please see attached notebook. This creates the longest continuous, unbroken BTCUSD dataset available on Kaggle, with no gaps and no erroneous values. It gives a much more comprehensive view of the market i.e. total volume across multiple exchanges.

Superior Performance: The combined index dataset has demonstrated superior 'mean average error' (MAE) metric performance when training machine learning models, compared to single-source datasets by a whole order of MAE magnitude.

Unbroken History: The combined dataset's continuous history is a valuable asset for researchers and traders who require accurate and uninterrupted time series data for modeling or back-testing.

https://i.imgur.com/8pw9H5E.png" alt="BTCUSD Dataset Summary">

https://i.imgur.com/AuFSkzb.png" alt="Combined Dataset Close Plot"> This plot illustrates the continuity of the dataset over time, with no gaps in data, making it ideal for time series analysis.

Included Resources:

Two Notebooks:

Dataset Usage and Diagnostics: This notebook demonstrates how to use the dataset and includes a powerful data diagnostics function, which is useful for all time series analyses.

Aggregating Multiple Data Sources: This notebook walks you through the process of combining multiple exchange datasets into a single, clean dataset. (Currently unavailable, will be added shortly)

Two of the most common questions that are often asked about cryptoassets are 'what is the intrinsic value (IV) of a cryptoasset?', and 'what makes one crypto asset more valuable that another asset?'.

In a complex market with literally thousands of instruments, RDA Ranking clarifies the intrinsic value of cryptoassets.

The index uses a proprietary algorithm to analyse asset attributes and compute their intrinsic value on 0 to N point scale - where 0 indicates no intrinsic value and N is the highest intrinsic value for a given asset.

The Market IV Level is defined as the maximum RDA points of all assets at any given point. The Market IV Level serves as a reference for the evolution of fundamental drivers of the cryptoasset industry. By definition, it is the higher frontier of intrinsic value of cryptoassets.

The dataset was collected for the period spanning between 01/07/2019 and 31/12/2022.The historical Twitter volume were retrieved using ‘‘Bitcoin’’ (case insensitive) as the keyword from bitinfocharts.com. Google search volume was retrieved using library Gtrends. 2000 tweets per day using 4 times interval were crawled by employing Twitter API with the keyword “Bitcoin. The daily closing prices of Bitcoin, oil price, gold price, and U.S stock market indexes (S&P 500, NASDAQ, and Dow Jones Industrial Average) were collected using R libraries either Quantmod or Quandl.

Dataset Overview Each row represents a unique log emitted during transaction execution: • Canonical positioning: (block_number, tx_index, log_index) • Emitting contract address • Primary event topic (topic_zero) • Additional topics (data_topics) • Raw event data payload

All fields are stored exactly as produced by the node, with direct RLP verifiability for topics, data, and contract address.

Every log includes a deterministic _tracing_id that links the record to its genesis event and upstream transaction, forming the foundation for decoded events, swaps, liquidity, NFT events, and custom protocol decoders in downstream BlockDB products.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates.

Schema List of columns exactly as delivered: • block_number BIGINT – Block number that contains the emitting transaction • tx_index INTEGER – Zero-based index of the transaction within the block • log_index INTEGER – Zero-based position of the log within the transaction • contract_address BYTEA – 20-byte address of the contract that emitted the log • topic_zero BYTEA – 32-byte primary topic hash identifying the event type (NULL for anonymous events) • data_topics BYTEA[] – Array of additional topics (topics[1..n]), as raw bytes • data BYTEA – Raw event data payload as emitted on-chain • _tracing_id BYTEA – Deterministic lineage identifier of this log record • _created_at TIMESTAMPTZ – Record creation timestamp • _updated_at TIMESTAMPTZ – Record last update timestamp

Notes • Primary key: (block_number, tx_index, log_index) guarantees canonical ordering and uniqueness. • Foreign key: (block_number, tx_index) links each log directly to its canonical transaction record. • Indexes on contract_address, topic_zero, and (contract_address, topic_zero) support fast protocol- or event-specific scans. • Binary values can be rendered as hex via encode(column, 'hex') in SQL for display or downstream joins.

Lineage & Integrity Direct RLP-verifiable fields: contract_address, topic_zero, data_topics, data, and log_index are all directly or indirectly validated against node RLP.

_tracing_id provides a deterministic, cryptographic handle for each log row, enabling: • Provenance tracking from raw logs to decoded events and higher-level features • Reproducible analytics and signal extraction • Cross-system consistency checks (RPC vs. indexers vs. internal warehouses)

Common Use Cases • Building decoded event layers (swaps, LP actions, mints, burns, governance events, NFT activity) • Reconstructing DEX activity and liquidity flows directly from raw logs • Protocol-specific analytics (AMMs, lending, perpetuals, bridges, staking) from first principles • Detecting MEV patterns, liquidations, and arbitrage events at log-level resolution

Quality • Verifiable lineage: deterministic cryptographic hashes per row • Reorg-aware ingestion: continuity and consistency across forks • Complete historical coverage: from chain genesis to present

Dataset Overview Canonical on-chain token reference for fungible and non-fungible assets, providing unified structure and lineage for every recognized contract. Each row represents a unique token or collection, traceable to its genesis event and ABI-decoded metadata.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Includes both native coins (ETH, BNB, AVAX, etc.) and token contracts (ERC-20, ERC-721, ERC-1155, ERC-4626, custom standards).

Schema List the columns exactly as delivered. • contract_address BYTEA - PK; 20-byte contract address • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • name TEXT - asset name (from ABI or native coin registry) • symbol TEXT - token symbol or ticker • decimals SMALLINT - number of decimal places for fungible tokens (NULL for NFTs) • metadata_uri TEXT - optional field for NFT metadata base URI (if applicable) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Notes • Use encode(contract_address,'hex') for hex presentation. • Metadata for each token type is retrieved deterministically via ABI decoding or registry sources. • If the ABI read was unsuccessful, the token is not present in this table.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Canonical token registry for normalization across DeFi datasets • Symbol, name, decimals lookups for accurate unit scaling in analytics • Cross-chain asset identity resolution • Foundation for NFT, LP token, and vault datasets • Integration layer for pricing engines, wallets, and indexers

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Canonical ERC-20 token reference with deterministic tracing at the row level. One row per token contract, with audit-grade lineage to the first recognition event and to parent/genesis derivations.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates.

Schema List the columns exactly as delivered. • contract_address BYTEA - PK; 20-byte ERC-20 contract address • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • name TEXT - asset name • symbol TEXT - token symbol or ticker • decimals SMALLINT - number of decimal places • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Notes • Use encode(contract_address,'hex') for hex presentation. • Metadata for each token type is retrieved deterministically via ABI decoding or registry sources. • If the ABI read was unsuccessful, the token is not present in this table.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Token registry to normalize joins for swaps, transfers, pools, and prices • Amount scaling via decimals for analytics, PnL, and model features • App backends: display names/symbols and validate token addresses

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

This dataset contains 4-hour interval OHLC data for the BTC/USDT trading pair, combined with the 🧠 Crypto Fear & Greed Index (FGI) on a daily basis, starting from 📅 March 25, 2020.

GitHub⭐

Perfect for 📈 time series analysis, 🧪 backtesting trading strategies, and exploring how market sentiment affects Bitcoin price movement.

📁 Contents: ⏰ timestamp: Datetime of each 4-hour candle (UTC)

🟢 open: Price at the start of the interval

🔴 close: Price at the end of the interval

🔼 high: Highest price during the interval

🔽 low: Lowest price during the interval

😨 Fear & Greed Index: Daily sentiment score (0–100)

📉 Fear & Greed Classification: Sentiment label (e.g., Extreme Fear, Greed)

🔗 Sources: 📡 OHLC data: From CoinGecko API

🧠 Fear & Greed Index: From Alternative.me API

Use this dataset to:

📊 Analyze historical BTC/USDT price trends

🧠 Correlate market sentiment with price action

🤖 Train sentiment-aware models or trading bots

🧩 Build crypto dashboards and visualizations

Dataset Overview Canonical registry of all DEX liquidity pools, normalized into the BlockDB schema for deterministic cross-chain analysis. Fees are modeled separately as versioned terms, so fee changes over time are tracked precisely and are joinable back to the pool.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Coverage includes: • Uniswap V2, V3, V4 • Balancer V2, PancakeSwap, Solidly, Maverick, Aerodrome, and others

Schema List the columns exactly as delivered.

liquidity_pools (base registry) • uid BIGINT NOT NULL - stable pool identifier (derived from address or pool_id) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • contract_address BYTEA NULL - 20-byte pool address (v2/v3-style) • pool_id BYTEA NULL - 32-byte pool id (v4-style / manager-based) • factory BYTEA NOT NULL - DEX factory / pool manager address • type_id INTEGER NOT NULL - pool type FK (constant-product, concentrated, stable/weighted, etc.) • pairnum NUMERIC(6) NULL - optional pair ordinal/descriptor • tokens BYTEA[] NOT NULL - array of 20-byte token addresses (order matches protocol convention) • asset_managers BYTEA[] NULL - per-token managers (e.g., Balancer) • amp NUMERIC(6) NULL - amplification for stable/weighted math • pool_type TEXT NULL - optional human-readable type label • weights NUMERIC(6,5)[] NULL - per-token weights in 0..1 (5 dp) • tick_spacing SMALLINT NULL - grid size for concentrated liquidity • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pool_fee_terms (versioned, non-overlapping) • pool_uid BIGINT NOT NULL - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • pool_fee NUMERIC(18,18) NOT NULL - Total fee fraction (e.g. 0.003 = 0.30 %) • user_fee_bps SMALLINT NULL - Optional user-side fee share (0–10 000) • protocol_fee_bps SMALLINT NULL - Optional protocol-side fee share (0–10 000) • fee_source TEXT NOT NULL - Provenance of fee rate (e.g. onchain:event) • fee_share_source TEXT NOT NULL - Provenance of fee split (e.g. onchain:param, docs) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Checks • At least one identifier present (contract_address or pool_id) and lengths enforced (20B/32B).

Notes • Fee terms are non-overlapping; each record defines a valid block-range. • Use liquidity_pool_fee_terms for historical fee reconstruction or to obtain the active fee at a given block.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common 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

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview The Level-2 (L2) stablecoin liquidity impact dataset provides quantized liquidity grids around the mid-price (typically ±10%) for all major USD-pegged stablecoin pairs. Each row represents a depth snapshot at a defined basis-point spacing (e.g. 10 bps), describing how much stablecoin can be executed before the price deviates by a certain percentage.

These grids allow analysts and developers to model depth curves, slippage, and peg resilience with high precision, fully reproducible from on-chain data.

Key traits • Focused on USD and major fiat-pegged tokens (USDC, USDT, DAI, FRAX, LUSD, crvUSD, etc.) • Schema-stable, versioned, and audit-ready • Real-time (WSS) and historical/EOD delivery • Fully verifiable lineage back to pool events and raw on-chain logs

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Coverage includes all major DEX protocols holding stablecoin pairs: • Uniswap V2, V3, V4 • Curve, Balancer, Aerodrome, Solidly, Maverick, Pancake, and others

Schema List the columns exactly as delivered. • snapshot_id BIGINT - unique identifier for each grid snapshot. • pool_uid BIGINT - reference to the liquidity pool (liquidity_pools.uid). • block_number BIGINT - block number of the originating event. • tx_index INTEGER - transaction index within that block. • log_index INTEGER - log index within the transaction. • token_in BYTEA - 20-byte ERC-20 address of the input token. • token_out BYTEA - 20-byte ERC-20 address of the output token. • current_price NUMERIC(78,18) - mid-price (token_out per 1 token_in, decimals-adjusted). • grid_step_bps SMALLINT - spacing between grid points, in basis points. • grid_radius_bps INTEGER - total radius of the grid window, in basis points. • grid_points SMALLINT - number of grid points; must equal radius/step + 1. • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

token_to_token_l2_points • snapshot_id BIGINT - reference to the parent snapshot (token_to_token_l2_snapshots.snapshot_id). • point_index SMALLINT - sequential index (0 … grid_points − 1). • offset_bps_abs INTEGER - absolute offset from the mid-price, in basis points. • size_in NUMERIC(78,18) - executable input amount required to reach this offset. • size_out NUMERIC(78,18) - corresponding output amount at that offset. • price_at_point NUMERIC(78,18) - average price (out / in) including impact.

(For hex display: encode(token_in,'hex'), encode(token_out,'hex').)

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Stablecoin peg analysis through liquidity depth modeling • Execution algorithm calibration (impact-aware order sizing) • Market-making and slippage profiling • Cross-chain peg risk and liquidity fragmentation studies • MEV and arbitrage signal extraction • AI/ML feature generation for depeg and volatility prediction

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview The Level-3 Stablecoin dataset provides complete tick-level liquidity grids for all Uniswap V3-style pools containing stablecoin pairs (e.g., USDC/USDT, DAI/USDC). Each snapshot represents the entire liquidity surface − showing the exact executable size, slippage, and price impact across the full tick range (−887 272 → +887 272).

Key traits • Focused on USD and major fiat-pegged tokens (USDC, USDT, DAI, FRAX, LUSD, crvUSD, etc.) • Schema-stable, versioned, and audit-ready • Real-time (WSS) and historical/EOD delivery • Built for deep-liquidity and peg-stability analytics

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Coverage includes all major DEX protocols holding stablecoin pairs: • Uniswap V2, V3, V4 • Curve, Balancer, Aerodrome, Solidly, Maverick, Pancake, and others

Schema List the columns exactly as delivered. • snapshot_id BIGINT - unique identifier for each grid snapshot. • pool_uid BIGINT - reference to the liquidity pool (liquidity_pools.uid). • block_number BIGINT - block number of the originating event. • tx_index INTEGER - transaction index within that block. • log_index INTEGER - log index within the transaction. • token_in BYTEA - 20-byte ERC-20 address of the input token. • token_out BYTEA - 20-byte ERC-20 address of the output token. • current_price NUMERIC(78,18) - mid-price (token_out per 1 token_in, decimals-adjusted). • grid_step_bps SMALLINT - spacing between grid points, in basis points. • grid_radius_bps INTEGER - total radius of the grid window, in basis points. • grid_points SMALLINT - number of grid points; must equal radius/step + 1. • reserves_in_adj NUMERIC(78,18) - adjusted reserve amount of the input token (decimals-normalized). • reserves_out_adj NUMERIC(78,18) - adjusted reserve amount of the output token (decimals-normalized). • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

token_to_token_l3_points • snapshot_id BIGINT - reference to the parent snapshot (token_to_token_l3_snapshots.snapshot_id). • point_index SMALLINT - sequential index (0 … grid_points − 1). • offset_bps_abs INTEGER - absolute offset from the mid-price, in basis points. • size_in NUMERIC(78,18) - executable input amount required to reach this offset. • size_out NUMERIC(78,18) - corresponding output amount at that offset. • price_at_point NUMERIC(78,18) - average price (out / in) including impact.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Peg-stability and liquidity-depth analysis for stablecoins • Execution cost and slippage modeling at tick-level precision • Liquidity surface visualizations for Uniswap V3/V4 pools • Cross-pool liquidity comparisons and routing research • Quantitative modeling for arbitrage, MEV, and impact forecasting

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

About the Dataset

This dataset was generated using the BitsCrunch API to provide insights and analytics for 1000 NFT collections. It focuses on metrics related to collection performance, trading activity, and market dynamics, enabling comprehensive analysis of the NFT ecosystem. Dataset Generation Process:

Collection Retrieval:
  The Collection by Chain API was used to retrieve a dataset of 1000 NFT collections, including their contract addresses and names.

Profile Data Enrichment:
  The Collection Profile API was utilized to fetch detailed metrics for each collection, including performance scores, trading activity, liquidity, and sentiment.

Data Cleaning and Structuring:
  The retrieved data was cleaned to ensure consistency and completeness.
  The data was structured into an Excel file format, where each row represents an NFT collection and each column provides a specific attribute or metric.

Key Features in the Dataset:

Collection Details:
  contract_address: The unique contract address of the NFT collection.
  collection_name: The name of each NFT collection.
  blockchain: The blockchain platform where the collection exists (e.g., Ethereum).
  chain_id: The identifier of the blockchain network.

Performance Metrics:
  collection_score: A score representing the overall performance of the collection.
  token_distribution_score: A score indicating the distribution of tokens within the collection.
  metadata_score: A score evaluating the quality of the metadata for the collection.
  holder_metrics_score: A score based on the holding patterns of users.

Trading Metrics:
  profitable_trades: The total number of profitable trades.
  loss_making_trades: The total number of loss-making trades.
  profitable_trades_percentage: The percentage of trades that were profitable.
  loss_making_trades_percentage: The percentage of trades that resulted in a loss.
  zero_profit_trades: The number of trades with zero profit.

Volume Metrics:
  profitable_volume: The total volume of profitable trades.
  loss_making_volume: The total volume of loss-making trades.

Market Dynamics:
  fear_and_greed_index: An index representing market sentiment for the collection.
  washtrade_index: An index indicating the presence of wash trading activity.
  market_dominance_score: A score representing the market dominance of the collection.

Investor Behavior:
  diamond_hands: The metric reflecting long-term holders in the collection.
  liquidity_score: A score representing the liquidity of the collection.

This dataset provides a robust foundation for data-driven insights, enabling visualization, statistical analysis, and machine learning applications related to NFT collections. It is particularly valuable for understanding market trends, evaluating collection performance, and detecting manipulative trading activities in the NFT space.

Dataset Overview Canonical registry of all verified Balancer V2 liquidity pools, normalized into the BlockDB schema for deterministic cross-chain analysis. Fees are modeled separately as versioned terms, so fee changes over time are tracked precisely and are joinable back to the pool.

This dataset provides the structural backbone for connecting Balancer V2 pool states with liquidity, price, and swap datasets.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full backfill to chain genesis with reorg-aware real-time ingestion. Covers all verified Balancer V2 deployments across supported EVM networks.

Schema List the columns exactly as delivered.

liquidity_pools (base registry) • uid BIGINT NOT NULL - stable pool identifier (derived from address or pool_id) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • contract_address BYTEA NULL - 20-byte pool address (v2/v3-style) • pool_id BYTEA NULL - 32-byte pool id (v4-style / manager-based) • factory BYTEA NOT NULL - DEX factory / pool manager address • type_id INTEGER NOT NULL - pool type FK (constant-product, concentrated, stable/weighted, etc.) • pairnum NUMERIC(6) NULL - optional pair ordinal/descriptor • tokens BYTEA[] NOT NULL - array of 20-byte token addresses (order matches protocol convention) • asset_managers BYTEA[] NULL - per-token managers (e.g., Balancer) • amp NUMERIC(6) NULL - amplification for stable/weighted math • pool_type TEXT NULL - optional human-readable type label • weights NUMERIC(6,5)[] NULL - per-token weights in 0..1 (5 dp) • tick_spacing SMALLINT NULL - grid size for concentrated liquidity • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pool_fee_terms (versioned, non-overlapping) • pool_uid BIGINT NOT NULL - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • pool_fee NUMERIC(18,18) NOT NULL - Total fee fraction (e.g. 0.003 = 0.30 %) • user_fee_bps SMALLINT NULL - Optional user-side fee share (0–10 000) • protocol_fee_bps SMALLINT NULL - Optional protocol-side fee share (0–10 000) • fee_source TEXT NOT NULL - Provenance of fee rate (e.g. onchain:event) • fee_share_source TEXT NOT NULL - Provenance of fee split (e.g. onchain:param, docs) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Checks • At least one identifier present (contract_address or pool_id) and lengths enforced (20B/32B).

Notes • Fee terms are non-overlapping; each record defines a valid block-range. • Use liquidity_pool_fee_terms for historical fee reconstruction or to obtain the active fee at a given block.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common 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

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Canonical registry of all verified Aerodrome Slipstream liquidity pools, normalized into the BlockDB schema for deterministic cross-chain analysis. Fees are modeled separately as versioned terms, so fee changes over time are tracked precisely and are joinable back to the pool.

This dataset provides the structural backbone for connecting Aerodrome Slipstream pool states with liquidity, price, and swap datasets.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full backfill to chain genesis with reorg-aware real-time ingestion. Covers all verified Aerodrome Slipstream deployments across supported EVM networks.

Schema List the columns exactly as delivered.

liquidity_pools (base registry) • uid BIGINT NOT NULL - stable pool identifier (derived from address or pool_id) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • contract_address BYTEA NULL - 20-byte pool address (v2/v3-style) • pool_id BYTEA NULL - 32-byte pool id (v4-style / manager-based) • factory BYTEA NOT NULL - DEX factory / pool manager address • type_id INTEGER NOT NULL - pool type FK (constant-product, concentrated, stable/weighted, etc.) • pairnum NUMERIC(6) NULL - optional pair ordinal/descriptor • tokens BYTEA[] NOT NULL - array of 20-byte token addresses (order matches protocol convention) • asset_managers BYTEA[] NULL - per-token managers (e.g., Balancer) • amp NUMERIC(6) NULL - amplification for stable/weighted math • pool_type TEXT NULL - optional human-readable type label • weights NUMERIC(6,5)[] NULL - per-token weights in 0..1 (5 dp) • tick_spacing SMALLINT NULL - grid size for concentrated liquidity • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pool_fee_terms (versioned, non-overlapping) • pool_uid BIGINT NOT NULL - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • pool_fee NUMERIC(18,18) NOT NULL - Total fee fraction (e.g. 0.003 = 0.30 %) • user_fee_bps SMALLINT NULL - Optional user-side fee share (0–10 000) • protocol_fee_bps SMALLINT NULL - Optional protocol-side fee share (0–10 000) • fee_source TEXT NOT NULL - Provenance of fee rate (e.g. onchain:event) • fee_share_source TEXT NOT NULL - Provenance of fee split (e.g. onchain:param, docs) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Checks • At least one identifier present (contract_address or pool_id) and lengths enforced (20B/32B).

Notes • Fee terms are non-overlapping; each record defines a valid block-range. • Use liquidity_pool_fee_terms for historical fee reconstruction or to obtain the active fee at a given block.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common 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

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Canonical, lineage-verified dataset of on-chain liquidity reserves capturing the complete state of AMM pools at block-level and real-time granularity. Each record represents a verifiable snapshot of a pool’s state - either its aggregate reserve vector or its fine-grained tick/bin liquidity distribution - linked deterministically to the on-chain event that produced it.

Supports all major AMM architectures - from even-distribution (V2-style) to concentrated (V3/V4-style) and bin/range-based models - with full reproducibility from raw logs.

Key traits • Protocol-aware coverage for V2, V3, V4, and hybrid AMM variants • Historical snapshots and reorg-aware real-time updates • Full tick-range from a minimum of -887272 to a maximum of 887272 • Highest granularity possible: Log-by-Log • Schema-stable, versioned, and audit-ready • Deterministic, traceable lineage from pool creation to latest reserve update

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Covers major protocols: Uniswap V2/V3/V4, SushiSwap V2/V3, PancakeSwap V2/V3, Aerodrome V1/Slipstream, Curve, Balancer, TraderJoe, Maverick, Solidly, and others.

Schema List the columns exactly as delivered.

liquidity_pools_reserves - pool-level snapshots • id BIGINT - identity primary key • pool_uid BIGINT - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • reserves NUMERIC(78,0)[] - raw reserves per token (V2-style or Balancer pools) • current_tick INTEGER - active tick for concentrated-liquidity pools • current_sqrt_price NUMERIC(49,0) - Q64.96-encoded sqrt price (sqrtP = value / 2^96) • current_bin INTEGER - bin index for bin-style AMMs • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pools_reserves_details - granular tick/bin distribution • snapshot_id BIGINT - FK → liquidity_pools_reserves(id) • pool_uid BIGINT - denormalized pool reference • tick INTEGER - single-tick record (Uniswap V3-style) • lower_tick INTEGER - lower bound of a range (position-based) • upper_tick INTEGER - upper bound of a range • bin_id INTEGER - bin index (for bin-style AMMs) • liquidity NUMERIC(38,0) - engine-native liquidity metric (e.g., Uniswap V3 L) • amount0 NUMERIC(78,0) - token0 amount at this locator (raw units) • amount1 NUMERIC(78,0) - token1 amount at this locator (raw units)

Notes • All reserve and amount values are in raw on-chain token units. • Apply ERC-20 decimals from erc20_tokens table when scaling for price or display. • One of the payloads must be present per liquidity_pools_reserves row.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Price, TVL, and slippage calculations across pools and chains • Routing and arbitrage research (depth, fee tiers, fragmentation) • Market-structure analytics and liquidity regime detection • Backtesting and AI modeling with verifiable pool states • Monitoring dashboards for protocol health, volatility, and liquidity shifts

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Synthetic Level-1 (±1.00%) stablecoin price-impact dataset derived from raw on-chain DEX swaps, reserves, and liquidity states. Each row quantifies how much size is executable before a 1 % price move occurs — a direct measure of market depth, peg resilience, and liquidity quality across chains and protocols.

Key traits • Focused on USD and major fiat-pegged tokens (USDC, USDT, DAI, FRAX, LUSD, crvUSD, etc.) • Schema-stable, versioned, and audit-ready • Real-time (WSS) and historical/EOD delivery • Fully verifiable lineage back to pool events and raw on-chain logs

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full history from chain genesis; reorg-aware real-time ingestion and updates. Coverage includes all major DEX protocols holding stablecoin pairs: • Uniswap V2, V3, V4 • Curve, Balancer, Aerodrome, Solidly, Maverick, Pancake, and others

Schema List the columns exactly as delivered. • id BIGINT – Surrogate row id. • pool_uid BIGINT NOT NULL – Pool identifier (FK → liquidity_pools(uid)). • block_number BIGINT - block number of the originating event. • tx_index INTEGER - transaction index within that block. • log_index INTEGER - log index within the transaction. • token_in BYTEA NOT NULL – 20-byte address of input token (FK → erc20_tokens(contract_address)). • token_out BYTEA NOT NULL – 20-byte address of output token (FK → erc20_tokens(contract_address)). • current_price NUMERIC(78,18) NOT NULL – Mid price at snapshot (token_out per 1 token_in, decimals-adjusted). • offset_bps SMALLINT NOT NULL (default 100) – Fixed move magnitude in basis points (±1.00%). • size_in NUMERIC(78,18) NOT NULL – Gross input needed to reach the ±100 bps target (excludes fee). • size_out NUMERIC(78,18) NOT NULL – Output received at that target (excludes fee). • target_price NUMERIC(78,18) NOT NULL – Mid price at the ±100 bps target (post-impact; use fee_bps from pools if needed). • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

(For hex display: encode(token_in,'hex'), encode(token_out,'hex').)

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common Use Cases • Stablecoin peg strength and depth analysis at ±1 % around USD target. • Liquidity risk and arbitrage screens across chains and DEXes. • Execution sizing and slippage modeling for large stablecoin trades. • Cross-pool comparisons of depth and fee impact in real time. • Backtesting & AI features for peg loss or depeg detection models.

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Canonical registry of all verified PancakeSwap V2 liquidity pools, normalized into the BlockDB schema for deterministic cross-chain analysis. Fees are modeled separately as versioned terms, so fee changes over time are tracked precisely and are joinable back to the pool.

This dataset provides the structural backbone for connecting PancakeSwap V2 pool states with liquidity, price, and swap datasets.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full backfill to chain genesis with reorg-aware real-time ingestion. Covers all verified PancakeSwap V2 deployments across supported EVM networks.

Schema List the columns exactly as delivered.

liquidity_pools (base registry) • uid BIGINT NOT NULL - stable pool identifier (derived from address or pool_id) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • contract_address BYTEA NULL - 20-byte pool address (v2/v3-style) • pool_id BYTEA NULL - 32-byte pool id (v4-style / manager-based) • factory BYTEA NOT NULL - DEX factory / pool manager address • type_id INTEGER NOT NULL - pool type FK (constant-product, concentrated, stable/weighted, etc.) • pairnum NUMERIC(6) NULL - optional pair ordinal/descriptor • tokens BYTEA[] NOT NULL - array of 20-byte token addresses (order matches protocol convention) • asset_managers BYTEA[] NULL - per-token managers (e.g., Balancer) • amp NUMERIC(6) NULL - amplification for stable/weighted math • pool_type TEXT NULL - optional human-readable type label • weights NUMERIC(6,5)[] NULL - per-token weights in 0..1 (5 dp) • tick_spacing SMALLINT NULL - grid size for concentrated liquidity • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pool_fee_terms (versioned, non-overlapping) • pool_uid BIGINT NOT NULL - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • pool_fee NUMERIC(18,18) NOT NULL - Total fee fraction (e.g. 0.003 = 0.30 %) • user_fee_bps SMALLINT NULL - Optional user-side fee share (0–10 000) • protocol_fee_bps SMALLINT NULL - Optional protocol-side fee share (0–10 000) • fee_source TEXT NOT NULL - Provenance of fee rate (e.g. onchain:event) • fee_share_source TEXT NOT NULL - Provenance of fee split (e.g. onchain:param, docs) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Checks • At least one identifier present (contract_address or pool_id) and lengths enforced (20B/32B).

Notes • Fee terms are non-overlapping; each record defines a valid block-range. • Use liquidity_pool_fee_terms for historical fee reconstruction or to obtain the active fee at a given block.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common 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

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.

Dataset Overview Canonical registry of all verified SushiSwap V2 liquidity pools, normalized into the BlockDB schema for deterministic cross-chain analysis. Fees are modeled separately as versioned terms, so fee changes over time are tracked precisely and are joinable back to the pool.

This dataset provides the structural backbone for connecting SushiSwap V2 pool states with liquidity, price, and swap datasets.

Chains and Coverage ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request). Full backfill to chain genesis with reorg-aware real-time ingestion. Covers all verified SushiSwap V2 deployments across supported EVM networks.

Schema List the columns exactly as delivered.

liquidity_pools (base registry) • uid BIGINT NOT NULL - stable pool identifier (derived from address or pool_id) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • contract_address BYTEA NULL - 20-byte pool address (v2/v3-style) • pool_id BYTEA NULL - 32-byte pool id (v4-style / manager-based) • factory BYTEA NOT NULL - DEX factory / pool manager address • type_id INTEGER NOT NULL - pool type FK (constant-product, concentrated, stable/weighted, etc.) • pairnum NUMERIC(6) NULL - optional pair ordinal/descriptor • tokens BYTEA[] NOT NULL - array of 20-byte token addresses (order matches protocol convention) • asset_managers BYTEA[] NULL - per-token managers (e.g., Balancer) • amp NUMERIC(6) NULL - amplification for stable/weighted math • pool_type TEXT NULL - optional human-readable type label • weights NUMERIC(6,5)[] NULL - per-token weights in 0..1 (5 dp) • tick_spacing SMALLINT NULL - grid size for concentrated liquidity • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

liquidity_pool_fee_terms (versioned, non-overlapping) • pool_uid BIGINT NOT NULL - FK → liquidity_pools(uid) • block_number BIGINT - first block where the token was recognized • block_time TIMESTAMPTZ - UTC timestamp when the block was mined • tx_index INTEGER - tx index for that event • log_index INTEGER - log index for that event • pool_fee NUMERIC(18,18) NOT NULL - Total fee fraction (e.g. 0.003 = 0.30 %) • user_fee_bps SMALLINT NULL - Optional user-side fee share (0–10 000) • protocol_fee_bps SMALLINT NULL - Optional protocol-side fee share (0–10 000) • fee_source TEXT NOT NULL - Provenance of fee rate (e.g. onchain:event) • fee_share_source TEXT NOT NULL - Provenance of fee split (e.g. onchain:param, docs) • _tracing_id BYTEA - deterministic row-level hash • _parent_tracing_ids BYTEA[] - hash(es) of immediate parent rows in the derivation graph • _genesis_tracing_ids BYTEA[] - hash(es) of original sources (genesis of the derivation path) • _created_at TIMESTAMPTZ - Record creation timestamp. • _updated_at TIMESTAMPTZ - Record last update timestamp

Checks • At least one identifier present (contract_address or pool_id) and lengths enforced (20B/32B).

Notes • Fee terms are non-overlapping; each record defines a valid block-range. • Use liquidity_pool_fee_terms for historical fee reconstruction or to obtain the active fee at a given block.

Lineage Every row has a verifiable path back to the originating raw events via the lineage triple and tracing graph: • _tracing_id - this row’s identity • _parent_tracing_ids - immediate sources • _genesis_tracing_ids - original on-chain sources This supports audits and exact reprocessing to source transactions/logs/function calls.

Common 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

Quality • Each row includes a cryptographic hash linking back to raw on-chain events for auditability. • Tick-level resolution for precision. • Reorg-aware ingestion ensuring data integrity. • Complete backfills to chain genesis for consistency.