# Information Source: https://docs.amberdata.io/asset-and-pair-data # Pair Definition The Pair Information endpoint delivers reference metadata for spot market trading pairs such as BTC\_USD on a specific exchange. It provides essential details including asset and exchange identifiers, unique Amberdata ARC references, and the historical data availability for pricing and related market data on a pair. # Pair Details This endpoint supports pair discovery and mapping workflows by returning standardized identifiers and coverage information. It is especially valuable when onboarding new pairs and confirming data history before querying timeseries endpoints. The response indicates when data for a pair first became available, helping manage expectations around historical completeness. # Pair API Endpoint [/price/new-instrument-pair-information](/http/price/new-instrument-pair-information) *** # Asset Definition The Asset Information endpoint displays reference metadata for individual spot market assets (e.g., BTC, ETH), including full names, standardized symbols, unique Amberdata ARC identifiers, and per-exchange data availability ranges. # Asset Details Ideal for asset cataloging, symbol-to-name resolution and exchange listing verification This endpoint returns one record per supported exchange-asset combination. It enables efficient filtering and validation in applications that need to understand where and how deep the dataset history is for the specified asset. # Asset API Endpoint [/price/new-asset-information](/http/price/new-asset-information) *** # Prices Source: https://docs.amberdata.io/asset-information # Pair Definition The Pair Price endpoint provides current or historical price data for a specified spot trading pair (e.g., BTC\_USDC), including the price in USD, associated timestamp, and volume traded in the base asset. This price is calculated across all exchanges that support the pair, on a volume weighted average price (VWAP). # Pair Details This endpoint is designed for retrieving actionable price points for individual spot pairs, making it suitable for real-time monitoring, valuation checks, dashboard displays, or integration into trading/pricing applications. The response includes the normalized pair identifier, USD-denominated price, precise timestamp (typically at a specific interval or latest available), and asset-volume traded. It supports filtering by date range and time interval (minute, hour or day) to retrieve targeted data points. # API Endpoint [/price/new-instrument-price](/http/price/new-instrument-price) *** # Asset Definition The Asset Price endpoint provides current or historical price data for a specified spot asset (e.g., BTC), including the price in USD, associated timestamp, and volume traded in the asset. This price is calculated across all exchanges that support the asset, on a volume weighted average price (VWAP). # Asset Details This endpoint is designed for retrieving actionable price points for individual spot assets, making it suitable for real-time monitoring, valuation checks, dashboard displays, or integration into trading/pricing applications. The response includes the normalized asset identifier, USD-denominated price, precise timestamp (typically at a specific interval or latest available), and asset-volume traded. It supports filtering by date range and time interval (minute, hour or day) to retrieve targeted data points. # API Endpoint [/price/new-asset-price](/http/price/new-asset-price) *** # Availability Coverage includes major tokens such as BTC, ETH, XRP, SOL, and USDT. Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | -------------------------- | | Binance | 2023-06-01 | 1hr, before 2025 then 1min | | Binance.us | 2023-06-01 | 1hr, before 2025 then 1min | | Bitstamp | 2023-06-01 | 1hr, before 2025 then 1min | | Bybit | 2023-06-01 | 1hr, before 2025 then 1min | | GDAX (Coinbase) | 2023-06-01 | 1hr, before 2025 then 1min | | Gemini | 2023-06-01 | 1hr, before 2025 then 1min | | OKEx (OKX) | 2023-06-01 | 1hr, before 2025 then 1min | | Poloniex | 2023-06-01 | 1hr, before 2025 then 1min | | itBit | 2024-03-05 | 1hr, before 2025 then 1min | | Mercado Bitcoin | 2024-03-25 | 1hr, before 2025 then 1min | | Bitget | 2024-09-24 | 1hr, before 2025 then 1min | | Huobi | 2024-09-24 | 1hr, before 2025 then 1min | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2025-02-19 | 1min | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | *** # Frequently Asked Questions **What is the reason for both an asset and pair price?** * Depending on the use case, you might want an overall price for an asset like Bitcoin. Or, you might need more specific pair data like SOL\_USD or similar. Our endpoints don't make you choose. **Do the info endpoints show the depth of the data, ie, how far back it goes?** * Yes. In the response you'll see a field labeled startDate which makes it easy to see how deep the dataset is. *** # API Changes & Deprecations Source: https://docs.amberdata.io/changelog/api-changes ## πŸ“¦ API Changes & Deprecations * **Arkham Spot & Futures Data Discontinued** – February 16, 2026 Read more * **OKCoin Data No Longer Available (Platform Rebranding to OKX)** – October 1, 2025 Read more * **Batch Endpoint Migration Notice** – March 6, 2025 Read more * **Batch Endpoint Behavior Changes** – January 8, 2025 Read more * **Batch Endpoint Retrieval Limits** – January 6, 2025 Read more # Fixes Source: https://docs.amberdata.io/changelog/fixes ## πŸ› Fixes & Clarifications * **BitMEX Volume Mapping Clarification** – February 14, 2025 Read more # Infrastructure & Improvements Source: https://docs.amberdata.io/changelog/infrastructure ## βš™οΈ Infrastructure & Improvements * **Upcoming Infrastructure Upgrade: Market Data API** – Effective March 6, 2026 Read more * **Upcoming API Compression Requirement** – Effective July 1, 2025 Read more * **S3 Path Recommendation** – February 1, 2025 Read more * **REST Historical Order Book Access Limited to 18 Months** – May 15, 2025 Read more # Product Updates Source: https://docs.amberdata.io/changelog/product-updates ## πŸš€ Product Updates * **Bullish Options Data** – May 7, 2026 Read More * **New Parameter: `metricType` for Futures Long/Short Ratio** – March 31, 2026 Read More * **Tokenized Equity Instruments Now Available!** – February 24, 2026 Read More * **New Exchange Coverage and Dataset Expansions** – February 13, 2026 Read More * **Arkham Spot & Futures Data Now Available** – August 29, 2025 Read More * **BitMart Futures Data Now Available** – July 1, 2025 Read More * **BitMart Spot Data Now Available** – June 12, 2025 Read More * **CoinW Spot Data Now Available** – May 27, 2025 Read more * **Coinbase International Spot & Futures** – April 10, 2025 Read more * **Bullish Spot Data** – April 4, 2025 Read more * **Upbit Spot Data** – April 29, 2025 Read more * **Hyperliquid Futures Data** – April 18, 2025 Read more * **Deribit Spot Data** – April 4, 2025 Read more * **New Spot Markets: Bitvavo, Blockchain.com, Phemex, OKCoin** – April 4, 2025 Read more * **HashKey Exchange Spot Data** – March 13, 2025 Read more * **Crypto.com Spot Data** – March 7, 2025 Read more * **KuCoin Spot & Binance Options Data** – March 3, 2025 Read more * **Gate.io Spot Data** – January 17, 2025 Read more # DeFi Analytics Source: https://docs.amberdata.io/cloudsync/cloudsync-blockchain-data-and-defi-analytics Comprehensive data, including DeFi protocol analytics (covering DEX trading, lending protocols, liquidity events, lending protocol events, stablecoin metrics, and more) across multiple networks, delivered via Amazon S3 for advanced research and DeFi strategy development. #### DEX Trades Raw trading data from major decentralized exchanges: | Sample Files | | ----------------------------------------------------------------------------------------- | | [Download](https://amberdata-samples.s3.amazonaws.com/defi/dex/trades/2026-02-15.parquet) | #### DEX Liquidity Events Liquidity pool addition and removal events: | Sample Files | | -------------------------------------------------------------------------------------------- | | [Download](https://amberdata-samples.s3.amazonaws.com/defi/dex/liquidity/2026-02-15.parquet) | ### Lending Protocol Data #### Protocol Events Raw lending, borrowing, and liquidation events from major DeFi protocols: | Protocol | Blockchain | Sample Files | | ----------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Aave v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/ethereum/aave/v2/protocol_lens-02-15-26.parquet) | | Aave v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/ethereum/aave/v3/protocol-events/protocol_lens-02-15-26.parquet) | | Aave v3 | Arbitrum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/arbitrum/aave/v3/protocol_lens-02-15-26.parquet) | | Aave v2 | Avalanche | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/avalanche/aave/v2/protocol_lens-02-15-26.parquet) | | Aave v3 | Avalanche | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/avalanche/aave/v3/protocol_lens-02-15-26.parquet) | | Aave v3 | Optimism | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/optimism/aave/v3/protocol_lens-02-15-26.parquet) | | Compound v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/ethereum/compound/v2/protocol-events/protocol_lens-02-15-26.parquet) | | MakerDAO | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/ethereum/makerdao/protocol-events/protocol_lens-02-15-26.parquet) | #### Daily Asset Metrics Aggregated daily metrics for individual assets across protocols: | Protocol | Blockchain | Sample Files | | ----------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Aave v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/asset_daily/blockchain=ethereum-mainnet/aavev2/summary-02-15-26.parquet) | | Aave v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/asset_daily/blockchain=ethereum-mainnet/aavev3/summary-02-15-26.parquet) | | Compound v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/asset_daily/blockchain=ethereum-mainnet/compoundv2/summary-02-15-26.parquet) | | Compound v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/asset_daily/blockchain=ethereum-mainnet/compoundv3/summary-02-15-26.parquet) | | MakerDAO | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/asset_daily/blockchain=ethereum-mainnet/makerdao/summary-02-15-26.parquet) | #### Daily Protocol Metrics Aggregated daily metrics for entire protocols: | Protocol | Blockchain | Sample Files | | ----------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Aave v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/protocol_daily/blockchain=ethereum-mainnet/aavev2/summary-02-15-26.parquet) | | Aave v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/protocol_daily/blockchain=ethereum-mainnet/aavev3/summary-02-15-26.parquet) | | Compound v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/protocol_daily/blockchain=ethereum-mainnet/compoundv2/summary-02-15-26.parquet) | | Compound v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/protocol_daily/blockchain=ethereum-mainnet/compoundv3/summary-02-15-26.parquet) | | MakerDAO | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/protocol_daily/blockchain=ethereum-mainnet/makerdao/summary-02-15-26.parquet) | #### Daily Stablecoin Metrics Focused metrics on stablecoin usage within lending protocols: | Protocol | Blockchain | Sample Files | | ----------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Aave v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/stablecoin_daily/blockchain=ethereum-mainnet/protocol=aavev2/summary-02-15-26.parquet) | | Aave v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/stablecoin_daily/blockchain=ethereum-mainnet/protocol=aavev3/summary-02-15-26.parquet) | | Compound v2 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/stablecoin_daily/blockchain=ethereum-mainnet/protocol=compoundv2/summary-02-15-26.parquet) | | Compound v3 | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/stablecoin_daily/blockchain=ethereum-mainnet/protocol=compoundv3/summary-02-15-26.parquet) | | MakerDAO | Ethereum | [Download](https://amberdata-samples.s3.amazonaws.com/defi/lending/metrics/stablecoin_daily/blockchain=ethereum-mainnet/makerdao/summary-02-15-26.parquet) | ## Data Field Descriptions #### DEX Trade Fields Comprehensive trading data from decentralized exchanges: | Field | Description | | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | | exchange | The name of the DEX (e.g., Uniswap, SushiSwap, PancakeSwap) | | timestamp | Timestamp when Amberdata received the data | | timestampNanoseconds | The nanosecond part of the timestamp where applicable | | isBuy | Indicates the direction of the trade: true means buy the base, sell the quote; false means sell the base, buy the quote | | price | The actual price at which the asset was traded (including slippage, but not fees) | | volume | The total amount of that asset that was traded | | tradeId | The exchange provided id of the trade | | logIndex | The index of the log within the transaction which included this trade event | | pairAddress | The address of the trading pair contract | | amountInBase | The amount of the base asset accepted in the trade | | amountInQuote | The amount of the quote asset accepted in the trade | | amountOutBase | The amount of the base asset returned in the trade | | amountOutQuote | The amount of the quote asset returned in the trade | | fromAddress | The address which initiated the trade (sender) | | toAddress | The recipient of the trade (receiver) | #### DEX Liquidity Fields Liquidity pool events and changes: | Field | Description | | --------------- | --------------------------------------------------------------------------------------------- | | exchangeName | The name of the DEX | | pairAddress | The address of the trading pair contract | | baseAddress | The address of the first underlying asset behind the pair | | quoteAddress | The address of the second underlying asset behind the pair | | address | The address of the asset for which this liquidity event is for (either base or quote address) | | timestamp | The timestamp associated with this record | | transactionHash | The hash of the transaction which included this liquidity event | | amount | The new amount of the underlying asset after this liquidity event | | liquidityPrice | The new price of the underlying asset after this liquidity event | #### Lending Protocol Fields **Protocol Events (Aave v2 & v3):** | Field | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------- | | account | The EOA (Externally Owned Account) that triggered this event | | action | The event that the EOA triggered in the smart contract (deposit, withdraw, borrow, repay, liquidate, etc.) | | amountNative | The amount of the asset in native units, normalized with the asset's decimals | | amountUSD | The amount of the asset in US dollars | | assetId | The smart contract address of the asset | | assetSymbol | The human readable, abbreviated name of the asset (e.g., ETH, USDC, DAI) | | blockNumber | The integer value identifying the block | | borrowRate | The interest rate for borrowing the asset | | borrowRateMode | Indicates whether the borrowRate is stable or variable | | liquidatee | The EOA being liquidated because they are under-collateralized | | liquidator | The EOA that is triggering the liquidation | | collateralAssetId | The smart contract address of the collateral asset | | collateralAssetSymbol | The human readable name of the collateral asset | | principalAssetId | The smart contract address of the borrowed asset | | principalAssetSymbol | The human readable name of the borrowed asset | | profitUSD | The amount in US dollars that the liquidator earned from triggering a liquidation | | timestamp | Indicates the datetime or epoch milliseconds of when the event took place | | transactionHash | The unique identifier of the transaction | ## Use Cases and Applications * **DEX Trading Analysis**: Study arbitrage opportunities, slippage patterns, and trading efficiency * **Liquidity Pool Analysis**: Calculate yield farming returns and impermanent loss patterns * **Lending Protocol Analysis**: Monitor interest rates, liquidations, and protocol health * **Protocol Comparison**: Compare efficiency and safety across different DeFi protocols * **Yield Strategies**: Optimize lending, borrowing, and liquidity provision strategies * **Risk Assessment**: Monitor lending protocol health and liquidation cascade risks * **Stablecoin Research**: Analyze peg stability and stablecoin usage across protocols ## Supported Networks and Protocols * **DEX Protocols**: Uniswap, SushiSwap, PancakeSwap, Balancer, Curve * **Lending Protocols**: Aave v2/v3, Compound v2/v3, MakerDAO * **Cross-Chain Coverage**: Multi-chain deployments across Ethereum, Arbitrum, Optimism, Polygon, Avalanche ## Getting Started ```python theme={null} # Load DEX trade data dex_trades = pd.read_parquet('dex_trades_sample.parquet') # Analyze trading volume by exchange volume_by_exchange = dex_trades.groupby('exchange')['volume'].sum() print("Trading volume by DEX:") print(volume_by_exchange) # Load Aave protocol events aave_events = pd.read_parquet('aave_protocol_events_sample.parquet') # Analyze lending vs borrowing activity activity_by_action = aave_events.groupby('action')['amountUSD'].sum() print("\nLending protocol activity:") print(activity_by_action) ``` ## Data Quality and Processing ### Data Freshness * **Real-time Processing**: Near real-time data ingestion and processing * **Historical Completeness**: Complete historical data from network/protocol genesis * **Cross-Chain Consistency**: Standardized field formats across all networks * **Quality Assurance**: Automated validation and error checking ### Technical Specifications * **File Formats**: Apache Parquet and CSV formats optimized for analytics * **Compression**: Efficient storage with fast query performance * **Partitioning**: Organized by date and blockchain/protocol for optimal access patterns * **Schema Evolution**: Backward-compatible updates as networks and protocols evolve ## Access Information ### Amazon S3 Access * **Requirements**: AWS credentials for Requester Pays bucket access * **Setup**: Include `x-amz-request-payer: requester` in all requests * **Contact**: Your Account Executive for credential provisioning ### Support Resources * **Technical Documentation**: Comprehensive guides for blockchain and DeFi data * **Sample Analysis**: Python notebooks with common analysis patterns * **Integration Support**: Assistance with data pipeline setup and optimization * **Research Community**: Access to blockchain and DeFi research insights # Derivatives Analytics Source: https://docs.amberdata.io/cloudsync/cloudsync-derivatives-analytics Advanced derivatives analytics data including enhanced options trades with market context, implied volatility surfaces, and comprehensive option chain data delivered via Amazon S3 and Snowflake. ## Derivatives Analytics Datasets (S3) | Dataset Type | Sample Files | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Decorated Trades | [Download](https://amberdata-samples.s3.amazonaws.com/derivatives/options/decorated_trade/2026-02-15.bybit.decorated_trade.parquet) | | Delta Surface Constant | [Download](https://amberdata-samples.s3.amazonaws.com/derivatives/options/delta_surface_constant/2026-02-15.binance.delta_surface_constant.parquet) | | Delta Surface Floating | [Download](https://amberdata-samples.s3.amazonaws.com/derivatives/options/delta_surface_floating/2026-02-15.deribit.delta_surface_floating.parquet) | | Level 1 Quote | [Download](https://amberdata-samples.s3.amazonaws.com/derivatives/options/level_1_quote/2026-02-15.okex.level_1_quote.parquet) | ## Snowflake Tables | Feature Type | Snowflake Table Name | | --------------------------- | ------------------------------------- | | Level 1 Pre/Post Trade Data | `DERIVATIVES_DECORATED_TRADE` | | Delta Surface Constant | `DERIVATIVES_DELTA_SURFACE_CONSTANT` | | Delta Surface Floating | `DERIVATIVES_DELTA_SURFACE_FLOATING` | | Gamma Exposure (GEX) | `DERIVATIVES_GAMMA_EXPOSURE_SNAPSHOT` | | Level 1 Option Chain | `DERIVATIVES_LEVEL_1_QUOTE` | ## Data Field Descriptions ### Decorated Trades Enhanced trade data with comprehensive pre/post trade market context: | Field | Description | | --------------------- | --------------------------------------------------------------------------- | | tradeId | The id of the trade | | instrumentNormalized | The name of the instrument in Amberdata format | | blockTradeId | The id of the block trade | | currency | The currency | | delta | The greek delta value of the underlying option | | gamma | The greek gamma value of the underlying option | | theta | The greek theta value of the underlying option | | vega | The greek vega value of the underlying option | | rho | The greek rho value of the underlying option | | exchangeTimestamp | The date & time as provided by the exchange | | expirationTimestamp | The expiration timestamp | | indexPrice | The index price (spot) | | instrument | The name of the instrument as provided by exchange | | isBuySide | Indicates whether the trade was on the buy side (true) or sell side (false) | | liquidation | True if the trade is the result of a liquidation | | numberOfLegs | The number of legs in the block trade | | openInterestChange | The change in open interest | | postTradeAskIv | The post-trade ask implied volatility | | postTradeAskPrice | The post-trade ask price | | postTradeAskVolume | The post-trade ask size | | postTradeBidIv | The post-trade bid implied volatility | | postTradeBidPrice | The post-trade bid price | | postTradeBidVolume | The post-trade bid size | | postTradeMarkIv | The post-trade mark implied volatility | | postTradeMarkPrice | The post-trade mark price | | postTradeMidIv | The post-trade mid implied volatility | | postTradeMidPrice | The post-trade mid price | | postTradeOpenInterest | The post-trade open interest | | preTradeAskIv | The pre-trade ask implied volatility | | preTradeAskPrice | The pre-trade ask price | | preTradeAskVolume | The pre-trade ask size | | preTradeBidIv | The pre-trade bid implied volatility | | preTradeBidPrice | The pre-trade bid price | | preTradeBidVolume | The pre-trade bid size | | preTradeMarkIv | The pre-trade mark implied volatility | | preTradeMarkPrice | The pre-trade mark price | | preTradeMidIv | The pre-trade mid implied volatility | | preTradeMidPrice | The pre-trade mid price | | preTradeOpenInterest | The pre-trade open interest | | price | The trade price | | priceHigh24h | The highest trade price in the past 24 hours | | priceLow24h | The lowest trade price in the past 24 hours | | priceUsd | The trade price (notional value) | | putCall | Whether this record is a put or a call | | strike | The strike price | | tickDirection | The direction of the tick | | tradeAmount | The trade size | | tradeIv | The trade implied volatility | | underlyingPrice | The underlying price (for Deribit options: futures price, not spot) | | volume24h | The 24hr rolling volume | ### Delta Surface Constant Implied volatility surfaces for fixed, standardized maturities: | Field | Description | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | hifiTimestamp | The data timestamp | | daysToExpiration | Remaining days to expiration (DTE) | | currency | The currency | | atm | The "at-the-money" implied volatility, weighted between closest OTM put and call based on strike distance vs underlying price | | delta50 | The IV for 50 delta (at-the-money) | | deltaCall05 | The IV for 5 delta call options | | deltaCall10 | The IV for 10 delta call options | | deltaCall15 | The IV for 15 delta call options | | deltaCall20 | The IV for 20 delta call options | | deltaCall25 | The IV for 25 delta call options | | deltaCall30 | The IV for 30 delta call options | | deltaCall35 | The IV for 35 delta call options | | deltaCall40 | The IV for 40 delta call options | | deltaCall45 | The IV for 45 delta call options | | deltaPut05 | The IV for 5 delta put options | | deltaPut10 | The IV for 10 delta put options | | deltaPut15 | The IV for 15 delta put options | | deltaPut20 | The IV for 20 delta put options | | deltaPut25 | The IV for 25 delta put options | | deltaPut30 | The IV for 30 delta put options | | deltaPut35 | The IV for 35 delta put options | | deltaPut40 | The IV for 40 delta put options | | deltaPut45 | The IV for 45 delta put options | | expirationTimestamp | The option expiration date | | indexPrice | The index price (spot) | | multiplier | The contract multiplier | | openInterest | The open interest at the time of this record | | underlyingPrice | Underlying futures price with the corresponding DTE | ### Delta Surface Floating Implied volatility surfaces for actual option expiration dates: | Field | Description | | ------------------- | ----------------------------------------------------------------------------------------------------------- | | hifiTimestamp | The data timestamp | | expirationTimestamp | The option expiration date | | currency | The currency | | atm | The "at-the-money" implied volatility, weighted between closest OTM put and call | | daysToExpiration | Remaining days to expiration (DTE) | | delta50 | The IV for 50 delta (at-the-money) | | deltaCall05-45 | The IV for call options at 5-45 delta levels (see Delta Surface Constant for individual field descriptions) | | deltaPut05-45 | The IV for put options at 5-45 delta levels (see Delta Surface Constant for individual field descriptions) | | indexPrice | The index price (spot) | | multiplier | The contract multiplier | | openInterest | The open interest at the time of this record | | underlyingPrice | Underlying futures price with the corresponding DTE | ### Level 1 Quote Real-time comprehensive option chain data with Greeks: | Field | Description | | ------------------------ | -------------------------------------------------------------------------------------------------- | | ask | The ask price | | askIv | The ask implied volatility | | askVolume | The ask size | | bid | The bid price | | bidIv | The bid implied volatility | | bidVolume | The bid size | | currency | The currency | | delta | The greek delta value of the underlying option | | gamma | The greek gamma value of the underlying option | | theta | The greek theta value of the underlying option | | vega | The greek vega value of the underlying option | | rho | The greek rho value of the underlying option | | exchangeTimestamp | The date & time as provided by the exchange | | expirationTimestamp | The expiration timestamp | | hifiTimestamp | The date & time of the aggregated record | | indexPrice | The index price (spot) | | instrument | The name of the instrument as provided by exchange | | instrumentNormalized | The name of the instrument in Amberdata format | | isAtm | Flag indicating if this is the at-the-money option for the given expiration cycle | | isCarryForward | Whether this record was carried forward from the previous data point (when no quote updates occur) | | isExchangeProvidedGreeks | Whether the Greeks were provided by the exchange or calculated by Amberdata | | markIv | The mark implied volatility | | markPrice | The mark price | | multiplier | The contract multiplier | | openInterest | The open interest at the time of this record | # Market Data Source: https://docs.amberdata.io/cloudsync/cloudsync-market Traditional cryptocurrency market data across spot, futures, and options markets delivered via Amazon S3 and Snowflake for comprehensive trading and analytics applications. ## S3 #### Spot Market Data (S3) | Feature Type | Sample Files | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | OHLCV | [Minutely](https://amberdata-samples.s3.amazonaws.com/market/spot/ohlcv/minutely/2026-02-15.gdax.btc_usd.00.parquet) β€’ [Hourly](https://amberdata-samples.s3.amazonaws.com/market/spot/ohlcv/hourly/2026-02-15.gdax.btc_usd.00.parquet) β€’ [Daily](https://amberdata-samples.s3.amazonaws.com/market/spot/ohlcv/daily/2026-02-15.gdax.btc_usd.00.parquet) | | Order Book Snapshots | [Download](https://amberdata-samples.s3.amazonaws.com/market/spot/order-book-snapshots/2026-02-15.gdax.btc_usd.00.parquet) | | Order Book Events | [Download](https://amberdata-samples.s3.amazonaws.com/market/spot/order-book-updates/2026-02-15.gdax.btc_usd.00.parquet) | | Tickers | [Download](https://amberdata-samples.s3.amazonaws.com/market/spot/tickers/2026-02-15.kraken.btc_usd.00.parquet) | | Trades | [Download](https://amberdata-samples.s3.amazonaws.com/market/spot/trades/2026-02-15.gdax.btc_usd.00.parquet) | #### Futures Market Data (S3) | Feature Type | Sample Files | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Funding Rates | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/funding-rates/2026-02-15.binance.BTCUSDT.00.parquet) | | Insurance Funds | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/insurance-funds/2026-02-15.okex.BTC-USD.00.parquet) | | Liquidations | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/liquidations/2026-02-15.binance.BTCUSDT.00.parquet) | | Long/Short Ratio | [Minutely](https://amberdata-samples.s3.amazonaws.com/market/futures/long-short-ratio/minutely/2026-02-15.binance.BTCUSDT.00.parquet) β€’ [Hourly](https://amberdata-samples.s3.amazonaws.com/market/futures/long-short-ratio/hourly/2026-02-15.binance.BTCUSDT.00.parquet) β€’ [Daily](https://amberdata-samples.s3.amazonaws.com/market/futures/long-short-ratio/daily/2026-02-15.binance.BTCUSDT.00.parquet) | | OHLCV | [Minutely](https://amberdata-samples.s3.amazonaws.com/market/futures/ohlcv/minutely/2026-02-15.binance.BTCUSD_PERP.00.parquet) β€’ [Hourly](https://amberdata-samples.s3.amazonaws.com/market/futures/ohlcv/hourly/2026-02-15.binance.BTCUSD_PERP.00.parquet) β€’ [Daily](https://amberdata-samples.s3.amazonaws.com/market/futures/ohlcv/daily/2026-02-15.binance.BTCUSD_PERP.00.parquet) | | Open Interest | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/open-interest/2026-02-15.deribit.BTC-PERPETUAL.00.parquet) | | Order Book Snapshots | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/order-book-snapshots/2026-02-15.deribit.BTC-20FEB26.00.parquet) | | Order Book Events | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/order-book-updates/2026-02-15.binance.BTCUSDT.00.parquet) | | Tickers | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/tickers/2026-02-15.deribit.BTC-PERPETUAL.00.parquet) | | Trades | [Download](https://amberdata-samples.s3.amazonaws.com/market/futures/trades/2026-02-15.deribit.BTC-PERPETUAL.00.parquet) | #### Options Market Data (S3) | Feature Type | Sample Files | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Liquidations | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/liquidations/2026-02-15.deribit.ETH-16FEB26-2075-P.00.parquet) | | OHLCV | [Minutely](https://amberdata-samples.s3.amazonaws.com/market/options/ohlcv/minutely/2026-02-15.deribit.BTC-15FEB26-69000-C.00.parquet) β€’ [Hourly](https://amberdata-samples.s3.amazonaws.com/market/options/ohlcv/hourly/2026-02-15.deribit.BTC-15FEB26-69000-C.00.parquet) β€’ [Daily](https://amberdata-samples.s3.amazonaws.com/market/options/ohlcv/daily/2026-02-15.deribit.BTC-17FEB26-69000-C.00.parquet) | | Open Interest | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/open-interest/2026-02-15.deribit.BTC-17FEB26-65000-C.00.parquet) | | Order Book Snapshots | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/order-book-snapshots/2026-02-15.deribit.BTC-18FEB26-72000-C.00.parquet) | | Order Book Updates | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/order-book-updates/2026-02-15.deribit.BTC-18FEB26-72000-C.00.parquet) | | Tickers | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/tickers/2026-02-15.deribit.BTC-18FEB26-71000-P.00.parquet) | | Trades | [Download](https://amberdata-samples.s3.amazonaws.com/market/options/trades/2026-02-15.deribit.BTC-25SEP26-70000-P.00.parquet) | ## Snowflake Tables All Snowflake tables are versioned. Below are the latest available versions. #### Spot (Snowflake) Available in the `MARKET_SPOT` schema. | Feature Type | Snowflake Table Name | | -------------------- | ------------------------ | | OHLCV (daily) | `OHLCV_DAILY_V1` | | OHLCV (hourly) | `OHLCV_HOURLY_V1` | | OHLCV (minutely) | `OHLCV_MINUTELY_V1` | | Order Book Events | `ORDER_BOOK_EVENT_V1` | | Order Book Snapshots | `ORDER_BOOK_SNAPSHOT_V1` | | Tickers | `TICKER_V1` | | Trades | `TRADE_V1` | #### Futures (Snowflake) Available in the `MARKET_FUTURES` schema. | Feature Type | Snowflake Table Name | | --------------------------- | ---------------------------- | | Funding Rates | `FUNDING_RATE_V1` | | Insurance Funds | `INSURANCE_FUND_V1` | | Liquidations | `LIQUIDATION_V1` | | Long/Short Ratio (daily) | `LONG_SHORT_RATIO_DAILY_V1` | | Long/Short Ratio (hourly) | `LONG_SHORT_RATIO_HOURLY_V1` | | Long/Short Ratio (minutely) | `LONG_SHORT_RATIO_HOURLY_V1` | | OHLCV (daily) | `OHLCV_DAILY_V1` | | OHLCV (hourly) | `OHLCV_HOURLY_V1` | | OHLCV (minutely) | `OHLCV_MINUTELY_V1` | | Open Interest | `OPEN_INTEREST_V1` | | Order Book Events | `ORDER_BOOK_EVENT_V1` | | Order Book Snapshots | `ORDER_BOOK_SNAPSHOT_V1` | | Tickers | `TICKER_V1` | | Trades | `TRADE_V1` | #### Options (Snowflake) Available in the `MARKET_OPTIONS` schema. | Feature Type | Snowflake Table Name | | -------------------- | ------------------------ | | Liquidations | `LIQUIDATION_V1` | | OHLCV (daily) | `OHLCV_DAILY_V1` | | OHLCV (hourly) | `OHLCV_HOURLY_V1` | | OHLCV (minutely) | `OHLCV_MINUTELY_V1` | | Open Interest | `OPEN_INTEREST_V1` | | Order Book Events | `ORDER_BOOK_EVENT_V1` | | Order Book Snapshots | `ORDER_BOOK_SNAPSHOT_V1` | | Tickers | `TICKER_V1` | | Trades | `TRADE_V1` | ## Data Field Descriptions ### Spot Market Fields #### Order Book Snapshots | Field | Description | | ----------------- | --------------------------------------------------------------------------- | | exchange | The name of the exchange | | pair | The name of the asset pair | | exchangeTimestamp | The last bid/ask updated timestamp if provided by the exchange | | isBid | Indicates if the order is a bid or ask: true for a bid and false for an ask | | timestamp | The time at which the order book snapshot took place | | receivedTimestamp | Timestamp when Amberdata received the order book snapshot | | sequence | The sequence number provided by the exchange (null if not provided) | | data | The order book data corresponding to the columns fields | | maxPrice | The maximum price for the asset pair | | minPrice | The minimum price for the asset pair | #### Spot Trades | Field | Description | | ----------------- | ---------------------------------------------------------------------------- | | exchange | The name of the exchange | | pair | The name of the asset pair | | exchangeTimestamp | The time at which the trade took place | | tradeId | The exchange provided id of the trade | | receivedTimestamp | The time Amberdata received the trade data | | isBuySide | Indicates if the trade is a buy or sell: true for a buy and false for a sell | | price | The price at which the asset was traded | | size | The total amount of that asset that was traded | #### Spot OHLCV | Field | Description | | ----------------- | --------------------------------------------------------------------------------------------------- | | exchange | The name of the exchange | | pair | The name of the asset pair | | exchangeTimestamp | The time at which the candle period starts | | open | The opening price of the trading pair for the specified time period | | high | The highest price of the trading pair during the specified time period | | low | The lowest price of the trading pair during the specified time period | | close | The closing price of the trading pair for the specified time period | | volume | The total volume of the trading pair traded during the specified time period, in the base currency | | quotedVolume | The total volume of the trading pair traded during the specified time period, in the quote currency | | count | The total number of trades executed for the trading pair within the specified time period | ### Futures Market Fields #### Funding Rates | Field | Description | | ----------------- | ------------------------------------------------- | | exchange | The name of the exchange | | instrument | The name of the instrument | | exchangeTimestamp | The time at which the event occurred | | fundingInterval | The funding interval for which data is available | | fundingRate | The funding rate for which data is available | | nextFundingRate | The next funding rate for which data is available | | nextFundingTime | The next funding time for which data is available | #### Liquidations | Field | Description | | ----------------- | ---------------------------------------------------------- | | exchange | The name of the exchange | | instrument | The name of the instrument | | exchangeTimestamp | The time at which the event occurred | | timestamp | The time at which the liquidation occurred | | orderId | The order identifier | | price | The price of the instrument at the time of the liquidation | | side | The direction of the trade | | volume | The volume liquidated | #### Open Interest | Field | Description | | ----------------- | ----------------------------------------- | | exchange | The name of the exchange | | instrument | The name of the instrument | | exchangeTimestamp | The time at which the event occurred | | type | The type of instrument | | value | The total outstanding number of contracts | ### Options Market Fields #### Options Trades | Field | Description | | ----------------- | ----------------------------------------------- | | exchange | The name of the exchange | | instrument | The name of the instrument | | exchangeTimestamp | The time at which the event occurred | | tradeId | The exchange provided id of the trade | | isBuySide | `true` if the trade is a buy, `false` otherwise | | price | The price at which the asset was traded | | size | The total amount of that asset that was traded | ## Use Cases and Applications ### Spot Market Applications * **Trading Strategy Development**: Backtest strategies using historical spot market data * **Market Making**: Analyze order book dynamics for algorithmic trading * **Price Discovery Research**: Study how prices form across different exchanges * **Arbitrage Detection**: Identify price differences across exchanges and timeframes * **Liquidity Analysis**: Understand market depth and trading patterns ### Futures Market Applications * **Funding Rate Analysis**: Study perpetual swap funding patterns and arbitrage opportunities * **Liquidation Monitoring**: Track large liquidation events and market impact * **Open Interest Tracking**: Monitor position changes and market sentiment * **Risk Management**: Calculate exposure and portfolio risk across futures positions * **Contango/Backwardation Studies**: Analyze futures curve structures ### Options Market Applications * **Volatility Analysis**: Study implied volatility patterns and surfaces * **Options Flow Analysis**: Track institutional and retail options activity * **Risk Management**: Monitor Greeks exposure and hedge portfolios * **Strategy Backtesting**: Test options strategies with historical data * **Market Structure Research**: Understand options market efficiency and pricing ### Integration Benefits * **Multi-Asset Analysis**: Correlate spot, futures, and options data * **Cross-Exchange Research**: Compare data across multiple exchanges * **Historical Depth**: Years of tick-level data for robust analysis * **Real-time Applications**: Fresh data for live trading and monitoring * **Academic Research**: Clean datasets for empirical finance studies # CloudSync Overview Source: https://docs.amberdata.io/cloudsync/cloudsync-overview Amberdata provides multiple options for accessing large historical datasets to power advanced analytics, research, and trading strategy development. Our **CloudSync** solutions are designed to overcome the throughput limitations of REST APIs, enabling efficient large-scale data analysis. ## Benefits ### Object Storage Advantages * **Large Historical Data** – Access large datasets in analytics-ready formats. * **Research Flexibility** – Run proprietary analyses and test strategies without API rate constraints. * **Cost Efficiency** – Avoid repeated API calls when retrieving extensive historical data. * **Pipeline Integration** – Easily connect to existing ETL, ELT, and analytics workflows. ### Cloud Data Warehouse Advantages * **High-Performance Queries** – Optimized for complex, large-scale analytical workloads. * **Seamless Data Integration** – Integrate with diverse data sources and workflows. * **Cloud-Native Scalability** – Scale storage and compute as your data needs grow. * **Enterprise-Grade Security** – Advanced compliance and security features. * **User-Friendly SQL Access** – Intuitive querying for analysts and engineers. * **Built-In Transformation** – Native tools for processing, cleansing, and enriching data. ## Delivery Methods ### Amazon S3 β€” Parquet Retrieve large historical datasets from Amazon S3 in Apache Parquet format, optimized for performance and compatibility with analytics tools. Apache Parquet format offers several key advantages: * **Columnar Storage** – Stores data by column instead of row, enabling highly efficient compression and encoding. * **High Performance** – Delivers faster processing for large datasets and complex analytical queries. * **Efficient Compression** – Achieves better compression ratios than row-based formats like JSON. * **Analytics-Optimized** – Designed for fast querying and analytical workloads. * **Seamless Integration** – Fits easily into existing data pipelines and big data ecosystems. * **Broad Compatibility** – Supported across major data warehousing, analytics, and machine learning platforms. ### Snowflake Data Warehouse Most datasets are available in Snowflake, providing scalable, cloud-native data warehousing with efficient storage, fast retrieval, and powerful SQL-based analysis. ## Getting Started ### Working with Parquet Files If you only want to see the available fields, download a sample parquet file and load it as a pandas dataframe: ```python theme={null} # Import the pandas library import pandas as pd # Replace 'your_parquet_file.parquet' with the path to your Parquet file parquet_file = 'your_parquet_file.parquet' # Load the Parquet file as a pandas DataFrame df = pd.read_parquet(parquet_file) # Display the data types of the DataFrame print(df.dtypes) ``` To read the actual parquet data: ```python theme={null} # Import the pandas library import pandas as pd # Replace 'your_parquet_file.parquet' with the path to your Parquet file parquet_file = 'your_parquet_file.parquet' # Read and display the data df = pd.read_parquet(parquet_file, engine='pyarrow') print(df.head()) ``` ## Access and Provisioning ### Amazon S3 Access Customers need their own AWS credentials for S3 access provisioning. Contact your Account Executive if you're interested in downloading data via S3. #### Important Access Requirements > **Note:** Our S3 data buckets are configured as Requester Pays buckets, meaning your company will be responsible for any Amazon data transfer fees incurred during downloads. To access the data, you must include the following in your request headers: > > * **Header**: `x-amz-request-payer: requester` > * **Parameter**: `--request-payer requester` (for CLI requests) Ensure this setting is included in all requests to avoid access issues. ### Snowflake Access Customers need their own Snowflake account for data sharing access. Visit [Snowflake's Marketplace](https://app.snowflake.com/marketplace/providers/GZTSZ75EDX/Amberdata) to access sample files, or [contact us](https://www.amberdata.io/contact-us) for full access. ## Next Steps Choose the delivery method that best fits your infrastructure and analytical needs: 1. **Amazon S3**: Ideal for downloading and storing large historical datasets for offline analysis 2. **Snowflake**: Perfect for real-time querying and advanced analytics with SQL Contact your Account Executive or [reach out to us](https://www.amberdata.io/contact-us) to discuss which option best suits your requirements. # Ethereum Active Validators Source: https://docs.amberdata.io/data-dictionary/analytics/active-validators Note: This dataset is updated daily and is available via Databricks, and Snowflake. *** # Description This metric indicates the number of active validators on the Ethereum network at a specific point in time. Understanding the number of validators is important for several reasons: * Network Health and Security: The Ethereum network relies on validators to secure and validate transactions through the Proof of Stake (PoS) consensus mechanism. Knowing the number of active validators helps assess the overall health and security of the network. A higher number of validators typically indicates a more decentralized and secure network, as it becomes more difficult for a single entity or a small group of validators to control the network. * Decentralization: Decentralization is a fundamental principle of blockchain networks like Ethereum. A higher number of validators implies a more distributed and decentralized network, which is less susceptible to censorship, attacks, or manipulation by a single entity. It helps ensure that the decision-making power is distributed among a larger and diverse set of participants. * Trust and Transparency: Transparency in the operation of a blockchain network is essential for users and developers. Knowing the number of validators and their behavior provides transparency into the network's operation, allowing participants to have more confidence in the system's integrity and security. * Validator Economics: For individuals or entities considering becoming validators on the Ethereum network, knowing the number of existing validators is important for assessing the economic incentives and potential rewards for participating in network validation. It helps potential validators make informed decisions about their participation. *** # Use Cases \*\*Traders: \*\*Traders can monitor validators as they impact the yield on staking ETH. It is the base from which all liquid staking tokens derive their yield. \*\*Analysts: \*\*Analysts want to know the number of validators on the Ethereum network to gauge its decentralization and security for their research and investment analysis. \*\*Researchers:\*\* Researchers find this metric valuable for studying network dynamics, governance, and the implications of validator distribution on blockchain performance and ecosystem stability. *** # Methodology Active Validators = sum(validators created) - sum(validators offline) *** # Frequently Asked Questions **How often is this chart updated?** * Daily. **Does this include any L2 data or just Ethereum?** * This chart is strictly Ethereum. *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/bitcoin-price-and-moving-averages *** # Description Price is often the primary reference point for analyzing asset performance. By applying technical indicators such as daily and weekly moving averages, it is possible to identify key market dynamics, including support and resistance levels, trend direction, and potential reversal patterns. Amberdata provides price data and moving average indicators for major assets, including Bitcoin (BTC) and Ethereum (ETH). This includes commonly used indicators such as the **50-day moving average (50DMA)** and the **200-day moving average (200DMA)**. These indicators are frequently used to identify market signals: * A **death cross** occurs when the 50DMA falls below the 200DMA, typically interpreted as a bearish signal that may precede a rebound. * In **uptrending markets**, moving averages often serve as support levels. * In **downtrending markets**, moving averages may act as resistance, indicating potential ceilings in price action. *** # Use Case These moving averages are often short- and mid-term price indicators, commonly used in traditional financial applications. *** # Methodology Price and moving averages are calculated by taking the average price over the last *n* days. *** *** # Bitcoin Yardstick Source: https://docs.amberdata.io/data-dictionary/analytics/bitcoin-yardstick *** # Description The Bitcoin Yardstick is a metric for Bitcoin that attempts to measure the P/E ratio, which typically assesses the value of a company's profits to its earnings to understand how valuable a company's stock is. For Bitcoin, that is the perceived value of the network over the value of energy used to maintain it. There are three notable conditions: **Cheap**: Yardstick \< -1Οƒ under the mean **Risky**: Yardstick > +2Οƒ above the Mean **Expensive**: Yardstick > 3Οƒ above the mean *** # Use Case The **Bitcoin Yardstick** is a long-term valuation metric that helps identify periods of potential price disparity relative to historical norms. It is designed to support investment strategies focused on cyclical market behavior and to contextualize price movements in relation to major historical events. The metric enables users to observe patterns such as: * **Overvaluation** during bull markets, when Bitcoin tends to appear "expensive." * **Undervaluation** during bear markets, when Bitcoin historically trades at relative discounts. * Extreme undervaluation conditions, such as those observed during major market disruptions (e.g., Bitcoin reaching its lowest relative value during the FTX bankruptcy in 2022). The Bitcoin Yardstick can be used to inform macro-level positioning by correlating historical price trends with market cycles and significant events. *** # Methdology Bitcoin Yardstick = Market cap / Hashrate, normalized by a 2-year rolling Z-score *** *** # Balance Buckets: Number of Addresses Source: https://docs.amberdata.io/data-dictionary/analytics/btc-balance-bucket-number-of-addresses *** # Description The Number of Addresses balance bucket provides an aggregation of the number of addresses and the total number of tokens held by addresses with various balances, ranging from small fractions to over 10,000 BTC or ETH. Coverage includes ETH and BTC. *** # Use Case \*\*Traders: \*\*Traders utilize the breakdown of addresses by balance to gauge network trends. Changes in the number of addresses within each bucket shift from liquid to illiquid balances, and variations in profitable addresses can guide buying and selling strategies. \*\*Analysts: \*\*Analysts leverage these metrics for enhancing portfolio analysis, focusing on profitability and wallet distribution to make informed recommendations. \*\*Researchers: \*\*Researchers employ this data to identify market trends and patterns in network behavior, aiding in comprehensive market studies. *** # Methodology The Number of Addresses Balance Bucket categorizes address balances into different groups, indicating the number of addresses and the total balance within each group: 1. If the amount is exactly 0, it's classified as '0 ETH/BTC'. 2. For amounts less than 0.000001, we round it to '0.000001 ETH/BTC'. 3. Amounts falling below 0.00001 but above the previous category are noted as '0.00001 ETH/BTC'. 4. This pattern continues upwards, with each category capturing progressively larger amounts: '0.0001', '0.001', '0.01', '0.1', '1', '10', '100', '1000', and '10000'. 5. Any amount 10,000 or above is classified into the '10000+' category. *** *** # Balance Buckets: Supply Held Source: https://docs.amberdata.io/data-dictionary/analytics/btc-balance-buckets-supply-held *** # Description The Supply Held metric compiles an aggregation of the total amount of an asset contained within various categorized buckets' specific ranges. Coverage includes ETH and BTC. *** # Use Cases **Traders** can use distribution data to make better buy or sell decisions by tracking shifts in holdings. **Analysts** can improve portfolio strategies with insights from balance trends. **Researchers** can identify market trends by analyzing how an asset is distributed across wallets. *** # Methodology The Supply Held metric categories ETH/BTC amounts into specific buckets: 1. If the amount is exactly 0, it's classified as '0 ETH/BTC'. 2. For amounts less than 0.000001, we round it to '0.000001 ETH/BTC'. 3. Amounts falling below 0.00001 but above the previous category are noted as '0.00001 ETH/BTC'. 4. This pattern continues upwards, with each category capturing progressively larger amounts: '0.0001', '0.001', '0.01', '0.1', '1', '10', '100', '1000', and '10000'. 5. Any amount 10,000 or above is classified into the '10000+' category. *** *** # ETF Holdings/Flow (BTC & ETH) Source: https://docs.amberdata.io/data-dictionary/analytics/btc-etf-flows Note: These datasets are available via REST API, Databricks, and Snowflake. *** # Description **BTC and ETH ETF Flows** track the net movement of assets into and out of wallets associated with exchange-traded funds (ETFs). These wallets represent ETF issuer holdings and are monitored to reflect investor sentiment and fund positioning. ETF wallets are **not always publicly disclosed** by issuers. As a result, wallet attribution is based on tracking and tagging performed by trusted on-chain analysts and researchers. While not 100% definitive, these wallet sets are curated with a high level of confidence. * A **net increase** in ETF wallet holdings generally reflects **bullish market sentiment**, indicating a rise in investor demand. * A **net decrease** suggests **bearish sentiment** or profit-taking activity. Tracking ETF flows also reveals competitive dynamics across issuers by highlighting relative changes in market share among different ETF products. *** # Use Case \*\*Traders: \*\*ETF flow data offers insights into short-term market sentiment and potential price movement. By analyzing net inflows or outflows, traders can better time market entries or exits and respond to changes in institutional investment behavior. \*\*Researchers: \*\*ETF flows serve as a proxy for institutional interest in BTC and ETH. Researchers use this data to study macro-level adoption trends, the integration of crypto into traditional finance, and investor responses to major regulatory or economic events. \*\*Analysts: \*\*Market analysts leverage ETF flow data to assess conviction in Bitcoin and Ethereum as investable assets. These insights inform investment strategy, asset allocation, and risk assessment. ETF flows also help analysts construct narratives around capital rotation, institutional behavior, and market health. *** # Methodology * **Wallet Attribution**\ A curated set of ETF-associated wallets is compiled using public tagging efforts by on-chain analysts. Sources include wallet lists from contributors such as *Hildobby* on [Dune](https://dune.com/queries/3378085) and entity attribution platforms like [Arkham](https://platform.arkhamintelligence.com/signup). (Note: wallet addresses are sourced from Dune, but Dune’s aggregated metrics are not used.) * **Balance Tracking**\ Amberdata’s blockchain infrastructure is used to calculate the historical balances of the identified wallets. These balances are tracked over time to compute **inflows**, **outflows**, and **net position changes** in BTC and ETH across ETF issuers. * **Asset Flow Calculation**\ Changes in wallet balances are analyzed on a regular interval (e.g., daily) to produce time series data on net flows, enabling both short-term monitoring and long-term trend analysis. *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/btc-hodl-wave *** # Description The BTC HODL Wave leverages on-chain data to categorize Bitcoin holdings by their age, ranging from less than one day to over five years. This visualization provides insights into investor behavior by illustrating shifts in holding durationsβ€”longer holding periods often reflect bullish sentiment, while shorter holding periods may indicate bearish tendencies. Historically, patterns within the HODL Wave have correlated with key market cycles and major price movements. For example, an increase in the proportion of long-held Bitcoin frequently precedes market peaks. This metric serves as a valuable tool for investors and analysts seeking to understand market dynamics and inform strategic decision-making. The BTC HODL Wave is updated on a **monthly** basis to reflect the latest holding period distributions. *** # Use Case **Traders** often leverage the Hodl Wave to pinpoint short-term trading opportunities by monitoring shifts in holding patterns. **Analysts** utilize the Hodl Wave to gauge broader market sentiment and its potential impact on Bitcoin's price stability and future movements. **Researchers** interested in cryptocurrency market economics and behavior utilize the Hodl Wave to study accumulation, distribution, and retention patterns among Bitcoin holders. *** # Methodology The Bitcoin HODL Wave methodology involves a detailed analysis of transaction outputs and inputs across the blockchain: 1. **Transaction and UTXO Analysis**\ All Bitcoin transactions and their corresponding Unspent Transaction Outputs (UTXOs) are examined. 2. **Input-Output Matching**\ Transactions are cross-referenced by matching outputs with inputs to identify spent outputs, i.e., those outputs that have subsequently been used as inputs in later transactions. 3. **Age Calculation**\ For each spent output, the elapsed time between when the output was created and when it was spent is calculated. 4. **Age Bucket Categorization**\ These time intervals are grouped into predefined age buckets representing different holding periods, enabling the visualization of how long coins have been held before being moved. *** *** # Daily Address Activity Source: https://docs.amberdata.io/data-dictionary/analytics/daily-address-activity *** # Description The Daily Address Activity metric measures network engagement by categorizing unique blockchain addresses as either active or passive. Active addresses are those generating outputs, while passive addresses are those involved as inputs. This distinction provides important insights into the health and transactional dynamics of the network by capturing the daily participation of addresses. This metric currently covers Ethereum (ETH) and Bitcoin (BTC) networks. *** # Use Case **Traders** can interpret changes in active address counts as potential market signalsβ€”an increase in active addresses may indicate buying pressure, while a decrease can suggest selling activity. \*\*Analysts \*\*leverage these metrics to construct risk models and assess network robustness. **Researchers** utilize this data to analyze correlations between address activity (new and existing) and other phenomena such as ordinal transactions or ETF interest. *** # Methodology **Passive Addresses / Inputs:** * **Daily Inputs:** Records of addresses acting as transaction inputs, tracked by date. * **Passive Addresses:** Count of unique addresses with inputs per day. * **New Inputs:** Count of distinct addresses appearing as inputs for the first time on a given day. **Active Addresses / Outputs:** * **Daily Outputs:** Records of addresses acting as transaction outputs, tracked by date. * **Active Addresses:** Count of unique addresses with outputs per day. * **New Outputs:** Count of distinct addresses appearing as outputs for the first time on a given day. **All Addresses:** * The total set of addresses participating in transactions as either inputs or outputs on a given day. *** *** # Daily New Addresses Source: https://docs.amberdata.io/data-dictionary/analytics/daily-new-addresses *** # Description The Daily New Addresses metric quantifies the number of blockchain addresses created within a specified timeframe, identified by their first recorded input or output transaction. This metric provides insight into the rate of new address creation, serving as an indicator of potential user adoption or shifts in network activity. Coverage includes Ethereum (ETH) and Bitcoin (BTC) networks. *** # Use Case **Traders** monitor changes in new address creation as potential market signals; increases may suggest heightened buying interest, while decreases might indicate reduced market participation. **Analysts** incorporate these metrics into risk assessments and models evaluating network health. **Researchers** examine correlations between new addresses and other metricsβ€”such as ordinal transactions or ETF interestβ€”to understand broader market dynamics and behavioral patterns. *** # Methodology **New Addresses (Inputs and Outputs):** * Data is derived from a combined list of daily input and output addresses, each associated with its transaction date. * **All Addresses:** The count of distinct addresses appearing as inputs or outputs per day. * **New Addresses:** The earliest day on which an address appears as either an input or output transaction. * **30-Day Moving Average (DMA):** A 30-day moving average calculated over the daily count of new addresses. * **365-Day Moving Average (DMA):** A 365-day moving average calculated over the daily count of new addresses. *** *** # Altcoin ATM hourly Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/altcoin-atm-hourly # Definition This endpoint returns the "At-The-Money" volatility profile for a specified altcoin pair. The payload will include various daysToExpiraton so users can see the term-structure. *** # Details The endpoint has hourly granularity. Amberdata uses a proprietary model to determined the "modelATM", the model uses various realized volatility weightings and dynamically adjusts the weightings to incorporate term-structure "Contango" and "Backwardation" dynamics. This "modelATM" is meant to represent theoretical implied volatility. *** # API Endpoints [/Altcoin ATM hourly](/http/analytics/derivatives/altcoin-atm-hourly) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------- | ----------------------- | ----------- | | All Exchanges | 2023-06-01 | Hourly | *** *** # Futures Basis Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/apr-basis # Definition The Basis Analysis involves calculating the difference between spot prices and underlying futures prices using quote data. This difference is converted into percentage terms and annualized to provide insights into the basis over time. Amberdata has two distinct endpoints for this data: Constant Maturity and Live Term Structure. *** # Details Using the **APR Basis Constant Maturities** endpoint, users can calculate the basis by analyzing the difference between spot prices and futures prices, converting this into percentage terms, and annualizing it. This endpoint focuses on constant maturity basis calculations by interpolating between expirations around a target "days-to-expiration" (DTE). For example, if the target DTE is 90 days, the basis is determined by identifying nearby expiration points, such as 70-day and 123-day, and linearly interpolating to estimate the 90-day basis. This approach helps users understand the cost of carry over fixed time horizons. The **APR Basis Live Term Structures** endpoint provides real-time analysis of the basis by continuously updating the difference between spot and futures prices. This live data allows users to assess the current market conditions and basis fluctuations as they happen, offering a dynamic view of the pricing structure. This real-time perspective is crucial for traders looking to make timely decisions based on the latest market information. *** # API Endpoints [/Apr-Basis Constant Maturity](/http/analytics/derivatives/apr-basis-constant-maturity) [/Apr-Basis Live Term Structure](/http/analytics/derivatives/apr-basis-live-term-structure) *** # Availability | Exchanges | Start Date (YYYY-MM) | Granularity | | ---------------------------------------------------------- | -------------------- | --------------------------------------- | | Binance, Bitmex, Bybit, Deribit, OKEx (OKX), Kraken, Huobi | 2022-08 | Constant Term: 15 min, Live Term: 5 min | *** # Frequently Asked Questions **How do these endpoints help traders understand futures pricing?** * These endpoints provide valuable insights into futures pricing. The APR-Basis Constant Maturity endpoint shows how the basis changes for a fixed time period, making it easier to compare different contracts. The APR-Basis Live Term Structure endpoint offers real-time updates on the basis, helping traders see current market conditions. Together, they help traders analyze and compare futures prices effectively. *** # Bid Ask Spread Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/bid-ask # Description Bid-Ask Spread measures the difference between the best bid and best ask prices for a particular instrument. It returns both: * The absolute spread (in quote currency) * The spread as a percentage of the mid-price This dual representation allows for cross-instrument and cross-exchange comparison of liquidity conditions. *** # Details This metric provides a view of market tightness and liquidity fragmentation. By analyzing how wide or narrow the spread is, traders can quickly identify: * The most liquid exchange for a given asset * Which instruments offer the best execution conditions The percentage spread is especially useful when comparing instruments with different quote currencies (e.g., BTC-USDT vs. BTC-USD vs. BTC-EUR), as it normalizes price scale effects. *** # API Endpoint [/derivatives-analytics-bid-ask-spread](/http/analytics/derivatives/bid-ask-spread) *** # Availability We cover all instruments on major exchanges like Binance, Deribit, OKX (Okex) and more. Please use the information endpoint to find all coverage and exact instruments. | Exchange | History | Depth Order Count | | :---------- | :-------------------------- | :---------------- | | Arkham | 2025-08-10 (end 2026-02-16) | Full | | Binance | 2024-01-01 | 1000 | | Bitmex | 2024-01-01 | Full | | Bybit | 2024-01-01 | 500 | | Deribit | 2024-01-01 | Full | | Hyperliquid | 2025-03-19 | 20 | | Kraken | 2024-01-01 | Full | | Okex (OKX) | 2024-01-01 | 2000 | *** # Frequently Asked Questions **How is the absolute spread calculated?** * `spread = bestAskPrice βˆ’ bestBidPrice` * This is returned in the quote currency of the instrument. **What does spreadPercent represent?** * It’s the absolute spread divided by the mid-price: * `spreadPercent = (spread / midPrice) Γ— 100` * This normalizes spread data across different pairs. # Block Volumes Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/block-volumes # Definition tforms but settled on Deribit. The Block Volumes endpoint specifically uses **Block Volumes** refer to the aggregated total volume of options trades on Deribit that were negotiated on third-party pla times and sales data tagged with third-party "Block Trade IDs", indicating that these trades were facilitated by platforms such as Paradigm and Greeks Live before being executed on Deribit. This endpoint provides a consolidated view of the volume traded through these block trades for each option instrument. *** # Details Data fields include: * **Exchange**: The exchange where the trade is settled * **Currency**: The underlying asset of the option * **Expiration Timestamp**: The expiration date and time of the option * **Strike**: The strike price of the option contract * **Put**/**Call**: The type of option, either a Put (P) or a Call (C) * **Contract Volume**: The number of contracts traded in the block trade *** # API Endpoints [/Block Volumes](/http/analytics/derivatives/block-volumes) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ----------- | | Deribit | 2019-04-01 | Tick-Level | *** # Frequently Asked Questions **What are Block Volumes, and how do they differ from regularly traded volumes on Deribit?** * Block Volumes represent trades negotiated on third-party platforms but settled on Deribit, often involving larger trade sizes. In contrast, regularly traded volumes on Deribit reflect trades executed directly through the exchange's order book. *** # Correlation, Beta and Realized Volatility Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/correlation-beta # Definition Correlation is a statistical measure that describes the strength and direction of a relationship between two variables. It is expressed on a scale from -1 to +1, where: +1 indicates a perfect positive correlation (both variables move in the same direction), -1 indicates a perfect negative correlation (one variable moves in the opposite direction to the other), 0 indicates no linear relationship between the variables. Crypto beta (Ξ²) is a measure that evaluates the relative volatility of a specific cryptocurrency asset compared to a broader market benchmark, such as a cryptocurrency index or another reference asset. Our data provides insights into how a particular crypto asset's price movements correlate with those of the benchmark. Realized volatility is a measure of the actual price fluctuations of a cryptocurrency asset over a specified period, based on historical data. It quantifies how much the price of the asset has changed over a set number of past trading days. This measure is calculated using high and low prices, often employing methods like the Parkinson method, which is known for its effectiveness in capturing volatility by considering the range of price movements. In the context of the Amberdata API, realized volatility provides valuable insights into the historical volatility of crypto assets, helping investors and analysts understand past market behavior and assess potential risk and stability. *** # Details For correlation, Amberdata shows the 30, 90, and 180-day rolling correlation between the first pair and second pair. For beta, Amberdata shows the 30, 90, and 180-day rolling beta between the first pair and second pair, in units of the first pair. For realized volatility, Amberdata shows the 30, 90, and 180-day Parkinson realized volatility for the first pair parameter. *** # API Endpoints [/Correlation, Beta, and Realized Volatility](/http/analytics/derivatives/correlation-beta-and-realized-volatility) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | --------------- | ----------------------- | ----------- | | Binance | 2025-01-23 | Daily | | GDAX (Coinbase) | 2016-01-01 | Daily | *** # Frequently Asked Questions **How can these measures help me understand and manage investment risk?** * Correlation helps investors understand the relationship between different investments, allowing them to spread out risk more effectively. Beta provides insights into how risky an investment is compared to the overall market, helping investors gauge potential volatility and returns. Realized volatility shows how much an investment's price has actually changed in the past, offering a practical view of market behavior. Together, these measures give investors a clearer picture of market dynamics, enabling smarter decisions to manage risk. *** # Decorated Trades Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/decorated-trades # Definition **Decorated Trades** provides a comprehensive view of option trades by including detailed data such as pre-trade and post-trade Best Bid and Offer (BBO) information. This endpoint enables users to analyze the traded prices, sizes, and implied volatilities, as well as compare these with the best bid and best ask prices and sizes. It also incorporates underlying futures prices, cash/spot market prices at the time of the trade, and the pre and post-trade open interest along with its impact. This enriched data set allows Amberdata to develop 30 proprietary heuristics to evaluate each trade from the taker's perspective, assuming dealers are passive counterparties. In contrast, Undecorated Trades consist of raw times and sales data that are not integrated with Level 1 quote data due to the unavailability of such data at the time of the trade. *** # Details The following data fields are available for detailed analysis of options trades for ETFs and crypto-related equities: * **Exchange Information**: The platform or exchange where the trade occurred. * **Timestamps**: Precise time of the trade. * **Trade ID**: A unique identifier for each trade. * **Instrument Details**: Information about the traded option, including strike price, expiration, and type (call/put). * **Trade Characteristics**: Traded price, size, and implied volatility. * **24-Hour Metrics**: Volume and price changes over the past 24 hours. * **Pre-Trade BBO Data**: Best bid and offer prices and sizes before the trade. * **Post-Trade BBO Data**: Best bid and offer prices and sizes after the trade. * **Option Greeks**: Delta, Gamma, Theta, Vega, and Rho values associated with the traded option. * **Open Interest**: The number of outstanding contracts before and after the trade, along with the trade's impact on open interest. * **Directional Indicators**: Metrics indicating whether the trade was buyer- or seller-initiated. *** # API Endpoints [/Decorated Trades](/http/analytics/derivatives/decorated-trades) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | ----------- | | Binance | 2025-03-07 | Tick-level | | Deribit | 2021-09-01 | Tick-level | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Tick-level | *** # Frequently Asked Questions **How do Decorated Trades differ from Undecorated Trades?** * Decorated Trades include enriched data with pre-trade and post-trade BBOs, traded prices, sizes, implied volatilities, and additional metrics such as underlying futures prices and open interest impacts. Undecorated Trades provides raw times and sales data without this integrated quote data. *** # Delta Surface Constant and Floating Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/delta-surfaces-constant-and-floating # Definition Delta Surfaces represent a three-dimensional visualization of the implied volatility surface across fixed delta points. The "Delta Surfaces" endpoints display the interpolated delta values for implied volatility (using the exchange "marks"). These surfaces are crucial for understanding how an option's implied volatility changes with respect to different delta anchors. Amberdata offers two types of delta surface endpoints: 1. **Constant Maturity Delta Surface**: Displays the surface for fixed time horizons, regardless of actual option expiration dates. 2. **Floating Delta Surface**: Displays the surface for actual expiration dates. *** # Details For a given target delta value, such as βˆ†25, the inside and outside delta points closest to the target are identified. For example, if βˆ†28 and βˆ†22 are the nearest deltas around the target βˆ†25, the mark implied volatilities at these deltas are converted into variances, which are then linearly interpolated. The resulting interpolated variance is subsequently converted back into implied volatility. When targeting a constant maturity, the same interpolation process is applied across different maturities to achieve a specific β€œdays-to-expiration” (DTE) value. In order to calculate a target delta or DTE, both an inside and outside point must be available. If an outside point does not exist, the target value is returned as null. For example, if the smallest delta available on an options chain is βˆ†7, and there is no delta less than βˆ†5 to serve as the outside point, the target βˆ†5 value cannot be calculated and thus returns null. *** # API Endpoints [/Delta Surfaces Constant](/http/analytics/derivatives/delta-surfaces-constant) [/Delta Surfaces Floating](/http/analytics/derivatives/delta-surfaces-floating) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------- | ------------------------ | ----------- | | Binance | 2025-03-07 | Minutely | | Deribit | 2019-04-01 to 2021-09-01 | Hourly | | Deribit | 2021-09-01 | Minutely | | Bybit, Lyra, Thalex | 2024-06-01 | Minutely | | OKEx (OKX) | 2021-12-16 to 2024-05-01 | Daily | | OKEx (OKX) | 2024-05-01 | Minutely | *** # Frequently Asked Questions **What's the difference between floating and constant maturity delta surfaces?** * Floating delta surfaces use actual option expiration dates, while constant maturity surfaces use fixed time horizons (e.g., 30, 60, 90 days). Constant maturity surfaces allow for easier comparison across different time periods. **How can I use delta surfaces in my trading or risk management strategy?** * Delta surfaces can be used to identify relative value opportunities, manage portfolio risk, design option strategies with specific delta exposures, and improve pricing models. They provide a comprehensive view of how options with different strikes and expirations are being valued by the mark. *** # Deribit VS Model Hourly Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/deribit-vs-model-hourly # Definition This endpoint compares the model "At-The-Money" volatility versus the implied volatility found on Deribit, in order to validate our proprietary "modelAtm". The payload will include various daysToExpiraton so users can see the term-structure. *** # Details Our model uses dynamic weighting of the realized volatility term-structure in order to mimic mean-reversion typically found in the implied volatility markets. Therefore the "modelAtm" is a representation of implied volatility. *** # API Endpoints [/Deribit VS Altcoin Model hourly](/http/analytics/derivatives/deribit-vs-model-hourly) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------ | ----------------------- | ----------- | | Deribit (BTC, ETH) | 2023-06-01 | Hourly | | Deribit (SOL) | 2023-06-01 | Hourly | *** *** # Funding Realized/Accumulated Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/fundingrealized # Definition Funding Realized/Accumulated refers to the payments made between traders holding long and short positions in perpetual futures contracts. These payments help keep the contract price in line with the spot market price. By looking at these funding payments, traders can understand the cost of maintaining their positions over time. *** # Details This endpoint captures the total funding payments exchanged between long and short positions in perpetual futures contracts over a specific period. This metric includes realized funding, which is the actual amount paid or received during each funding interval, and accumulated funding, which aggregates these payments over time. This data is crucial for evaluating the financial impact of funding rates on open positions, helping traders make informed decisions about managing their trades and understanding the cost dynamics of holding perpetual contracts. *** # API Endpoints [/Funding Realized/Accumulated](/http/analytics/derivatives/funding-realized-accumulated#funding-realized-accumulated) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------- | ----------------------- | ----------- | | All Exchanges | 2022-01-01 | 8-hours | *** # Frequently Asked Questions **How does the funding rate impact my trading strategy in perpetual futures?** * This question is common because understanding the funding rate is crucial for managing the costs associated with holding positions in perpetual futures. The funding rate determines periodic payments between long and short positions, impacting profitability. Traders need to consider whether they will pay or receive funding fees, as these can affect their overall returns. By analyzing funding rates, traders can adjust their strategies to optimize for costs and potential gains, ensuring they align with market conditions. *** # Gamma Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/gamma-normalized-snapshots # Definition The Gamma Normalized in USD chart depicts the impact of GEX in terms of million dollars notional in the underlying asset for a 1% move in spot prices. This reflects the sum of the total outstanding gamma exposure across dealers. Gamma Snapshots (GEX) calculates the gamma exposure of Market Makers (MMs) and the number of underlying contracts they must trade to maintain a delta-hedged book. *** # Details * **Gamma Normalized in USD:** * Displays the total impact of GEX in terms of notional USD for a 1% move in spot prices. * Represents the cumulative gamma exposure across all dealers. * **Gamma Snapshots (GEX):** * GEX calculates the gamma exposure of Market Makers and their required number of underlying contracts to stay delta-hedged. * Uses the DIRECTION algorithm, which employs over 30 heuristics to estimate the trade direction of initiators/aggressors and identify likely Market Makers. * Tracks trades at a millisecond level to compute and maintain a database of gamma exposure. * Aggregates GEX values by multiplying with the gamma value of specific expirations and summarizes at the strike level. *** # API Endpoints [/Gamma Normalized in USD](/http/analytics/derivatives/gamma-normalized-in-usd) [/Gamma Snapshots (GEX)](/http/analytics/derivatives/gamma-snapshots-gex) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------------------- | ----------------------- | ----------- | | Deribit | 2019-08-23 | Daily | | Bybit
Lyra
Thalex
OKeX (OKX) | 2024-06-01 | Daily | *** # Frequently Asked Questions **What does the "Gamma Normalized in USD" chart represent?** * It shows the total impact of GEX in million dollars notional for a 1% move in spot prices, summarizing the total outstanding gamma exposure across dealers. **What is the role of the DIRECTION algorithm in Gamma Snapshots (GEX)?** * The DIRECTION algorithm estimates the correct trade direction and identifies Market Makers by analyzing order book data, which is then used to compute and maintain gamma exposure. **More information** [https://x.com/genesisvol/status/1555632200694960128](https://x.com/genesisvol/status/1555632200694960128) *** # Implied vs Realized Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/implied-realized # Definition The Implied vs Realized Volatility features provide a comparison between the implied volatility and realized volatility of a crypto asset's underlying index price or spot value. This is a **Binance and Deribit-only** endpoint and is exclusive to the crypto derivatives exchanges. The endpoint calculates the close-to-close realized volatility using hourly data for both 7-day and 30-day realized volatility calculations. It then returns the at-the-money (ATM) implied volatility for select constant maturities: 7-DTE (days-to-expiration), 30-DTE, 60-DTE, 90-DTE, and 180-DTE. *** # Details 1. Realized Volatility Calculation: * The endpoint uses the underlying index or spot price to calculate the close-to-close realized volatility on an hourly basis. * Both 7-day and 30-day realized volatility metrics are provided. * Realized volatility represents the actual historical volatility observed in the market. 2. Implied Volatility Data: * The endpoint returns the at-the-money (ATM) implied volatility for specific constant maturities. * These constant maturities include 7-DTE, 30-DTE, 60-DTE, 90-DTE, and 180-DTE. * Implied volatility is the market's expectation of future volatility, as reflected in option prices. The user can then compare the realized volatility and implied volatility of the market to determine the relative value of options. *** # API Endpoints [/Implied vs Realized](/http/analytics/derivatives/implied-vs-realized) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ----------- | | Binance | 2025-03-08 | Minutely | | Deribit | 2019-04-01 | Minutely | *** *** # Instruments Most Traded Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/instruments-most-traded # Definition The Instruments Most Traded endpoint aggregates total trading volume by option instruments across selected exchanges and currency types. It provides insights into which instruments are the most frequently traded, offering a snapshot of trading activity. *** # Details The endpoint includes the following data fields: * **Exchange**: The exchange where the trading data was collected. * **Currency**: The currency type involved in the trading activity. * **Instrument**: The specific option instrument being traded. * **Contract Volume:** The total volume of contracts traded for the instrument. *** # API Endpoints [/Instruments Most Traded](/http/analytics/derivatives/instruments-most-traded) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | --------------------- | | Binance | 2025-03-07 | Tick-Level Aggregated | | Deribit | 2019-04-01 | Tick-Level Aggregated | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Tick-Level Aggregated | *** # Frequently Asked Questions **What does the total contract volume indicate?** * The total contract volume shows how many contracts of a specific option instrument have been traded. It helps to understand the trading activity for that instrument. *** # Level 1 Quotes Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/level-1-quotes # Definition Level 1 Quotes refer to the best bid and ask prices and sizes for a given financial instrument at a particular point in time. In the context of options, Level 1 Quotes provide the most competitive prices at which an option can be bought or sold. The Level 1 Quotes endpoint displays the first observation of these option prices for every timestamp. This endpoint returns the "Level 1" option chain with associated volatilities, Greeks, and underlying prices. This is the core underlying options data for many analytics. *** # Details Level 1 Quotes are essential for traders and investors to gauge the current market for an option. They represent the most basic and crucial information about an option's pricing and liquidity. Data fields include: * **Bid price**: The highest price a buyer is willing to pay for the option * **Ask price:** The lowest price a seller is willing to accept for the option * **Bid size**: The number of contracts available at the bid price * **Ask size**: The number of contracts available at the ask price * **Option prices**: The current market prices for the option * **Implied volatilities**: A measure of the market's expectation of future volatility * **Exchange "marks"**: The prices set by the exchange, often used as a reference * **24h volume**: The total number of contracts traded in the last 24 hours * **Open interest**: The total number of outstanding contracts * **Associated Greeks**: Delta, Gamma, Theta, Vega, and Rho, derived from the option "marks" *** # API Endpoints [/Level 1 Quotes](/http/analytics/derivatives/level-1-quotes) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------- | ------------------------ | ----------- | | Binance | 2025-03-07 | Minutely | | Deribit | 2019-04-01 to 2021-09-01 | Hourly | | Deribit | 2021-09-01 | Minutely | | Bybit, Lyra, Thalex | 2024-06-01 | Minutely | | OKEx (OKX) | 2021-12-16 to 2024-05-01 | Daily | | OKEx (OKX) | 2024-05-01 | Minutely | *** # Frequently Asked Questions **How do Level 1 quotes for crypto options differ from those for traditional equity options?** * The core concept is the same, but crypto options markets may be more volatile and less liquid than traditional equity options markets. This can lead to wider bid-ask spreads and more frequent price updates in Level 1 quotes for crypto options. *** # Moneyness Surfaces Constant and Floating Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/moneyness-surfaces-constant-and-floating # Definition Moneyness Surfaces provide a structured view of implied volatility relative to an option's moneyness, rather than its absolute strike price. This approach normalizes volatility analysis, making it easier to compare different expirations and market conditions. Amberdata offers two types of moneyness surface endpoints: * **Constant Moneyness Surface**: Displays implied volatility across fixed moneyness levels for constant days-to-expiration horizons, allowing for consistent historical analysis. * **Floating Moneyness Surface**: Displays implied volatility across fixed moneyness levels for active expirations. These surfaces help traders and analysts better understand volatility skews, risk exposure, and market dynamics in a standardized format. *** # Details Moneyness measures the relative position of an option’s strike price compared to its underlying asset price. Here, lognormal moneyness is computed using the corresponding futures price and a reference point, providing a consistent framework across expirations. The dataset uses SVI calibration to ensure smooth and arbitrage-free volatility surfaces, which can be applied to risk modeling, option pricing, and quantitative research. *** # API Endpoints [/Moneyness Surfaces Floating](/http/analytics/derivatives/moneyness-surfaces-floating) [/Moneyness Surfaces Constant](/http/analytics/derivatives/moneyness-surfaces-constant) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------ | ----------------------- | ----------- | | Deribit (BTC, ETH) | 2019-04-01 | Hourly | *** # Frequently Asked Questions **How is lognormal moneyness calculated in this dataset?** * Lognormal moneyness is determined using the natural logarithm of the moneyness price divided by the futures price at a given reference point. This standardization helps normalize volatility structures across different expirations and market conditions. **Why is this dataset only available for BTC and ETH on Deribit?** * Currently, Deribit is the primary exchange offering deep liquidity and a robust options market for BTC and ETH. The SVI calibration process relies on high-quality data, which is best suited to markets with significant trading activity and available derivatives. *** # Open Interest Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/open-interest-add # Definition Open interest in the context of futures and perpetual contracts refers to the total number of outstanding contracts that have not yet been settled. It is a key indicator of market activity and liquidity, reflecting the level of participation in the market. High open interest suggests strong engagement from traders and can indicate the strength or weakness of price trends. By monitoring open interest, traders and analysts can gain insights into market sentiment and potential future price movements, helping them make informed trading and investment decisions. *** # Details This endpoint returns the total asset open interest for both futures and perpetuals across the various exchanges. The open interest is returned in raw coin amounts and millions of dollars. Data fields include: * Timestamp: This represents the timestamp * Exchange: The represents the exchange * Coin: This is the total open interest in coin units * USD: This is the total open interest in millions of USD units *** # API Endpoints [/Open Interest](/http/analytics/derivatives/open-interest) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------- | ----------------------- | ----------- | | All Exchanges | 2022-08-01 | Hourly | *** # Frequently Asked Questions **How does open interest help traders understand market trends and sentiment in crypto futures?** * Open interest shows the total number of unsettled futures contracts, indicating market activity. When open interest rises, it suggests new money is entering the market, supporting the current trend. If it falls, it might mean the trend is weakening. By watching open interest, traders can better understand market sentiment and decide when to enter or exit trades. *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/options-overview # Definition Our Options endpoints provide comprehensive data and insights into the options market. From volatility and risk metrics to open interest and volume metrics, trade details, and options scanner data, these endpoints offer a granular view of the market. They allow users to analyze different aspects of the options market, including trading activity, market sentiment, trading strategies, and much more. *** # Details Understanding the options market requires a wide range of data points and metrics. Our Options endpoints offer a wide variety of data, allowing users to gain a comprehensive understanding of the market. The Volatility endpoints provide insights into market volatility and calibrated volatility surfaces. They allow users to understand the implied volatility skew, portfolio scenarios, and the continuous implied volatility. The Open Interest and Volume Metrics endpoints provide insights into the open positions held by traders and trading volumes. They cover global open interest, put-call ratios, volume turnover, and notional values. The Trades Metrics endpoints provide granular details about trading activities. They allow users to access data on historical trades, the order book, gamma exposure through proprietary volume direction, and different trading strategies. Lastly, the Options Scanner endpoints provide in-depth insights into option trading activities. They offer data about the net volumes of trades over selected periods, the cumulative net positioning of traders, and block trades. Note: Trial API keys only support 1 year of data history. *** # Option Yields Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/options-yields # Definition The Option Yields endpoint calculates the yields for two common option strategies: Covered Call and Cash Secured Put. **Covered Call**: This strategy involves selling a call option while being long on the underlying asset. The yield is calculated based on the difference between the proceeds from selling the call and the cost of acquiring the underlying asset. **Cash Secured Put**: This strategy involves selling a put option while holding enough cash to cover the potential purchase of the underlying asset. The yield is based on the difference between the proceeds from selling the put and the cash balance maintained. *** # Details The Option Yields endpoint calculates yields for two options strategies: **Covered Call:** * **Absolute Yield** is calculated by dividing the proceeds from selling the call option by the initial position in the underlying asset. * **Annualized Yield** is obtained by multiplying the Absolute Yield by the factor representing the number of minutes in a year (525,600) divided by the minutes left until the option expires. **Cash Secured Put:** * **Absolute Yield** is determined by dividing the proceeds from selling the put option by the initial cash position. * **Annualized Yield** is calculated by multiplying the Absolute Yield by the factor representing the number of minutes in a year (525,600) divided by the minutes remaining until the option expires. *** # API Endpoints [/Options Yields](/http/analytics/derivatives/options-yields) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | ----------- | | Binance | 2025-03-07 | Hourly | | Deribit | 2019-04-01 | Hourly | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Hourly | *** # Frequently Asked Questions **How is the Absolute Yield for a Covered Call strategy calculated?** * The Absolute Yield is calculated by dividing the proceeds from selling the call option by the initial position in the underlying asset. **What is the purpose of calculating the Annualized Yield for a Covered Call?** * The Annualized Yield provides an annualized rate of return based on the Absolute Yield, adjusted for the time remaining until the option’s expiration. **How is the Absolute Yield for a Cash Secured Put strategy determined?** * The Absolute Yield is determined by dividing the proceeds from selling the put option by the initial cash position. **Why is the Annualized Yield important for a Cash Secured Put strategy?** * The Annualized Yield shows the return on the cash-secured put option on an annual basis, accounting for the time remaining until expiration. **What factors are needed to calculate Annualized Yields?** * To calculate Annualized Yields, you need the Absolute Yield and the number of minutes left until the option expires. *** # Order Book Depth Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/order-book-depth # Description Order Book Depth shows how much liquidity is available at varying distances from the best-bid/best-ask price, measured in basis points (bps). This provides a snapshot of market robustness and order book structure. *** # Details This metric analyzes both bid and ask side liquidity within configurable percentage ranges from the best-bid/best-ask price. By aggregating depth across tranches like 10bps, 50bps, or 100bps, it becomes easier to identify where meaningful liquidity resides. Liquidity concentration (e.g., most bids sitting within 20bps) can help assess potential slippage and execution quality, especially during large trades or volatility spikes. *** # API Endpoint [/derivatives-analytics-order-book-depth](/http/analytics/derivatives/depth) *** # Availability We cover all instruments on major exchanges like Binance, Deribit, OKX (Okex) and more. Please use the information endpoint to find all coverage and exact instruments. | Exchange | History | Depth Order Count | | :---------- | :-------------------------- | :---------------- | | Arkham | 2025-08-10 (end 2026-02-16) | Full | | Binance | 2024-01-01 | 1000 | | Bitmex | 2024-01-01 | Full | | Bybit | 2024-01-01 | 500 | | Deribit | 2024-01-01 | Full | | Hyperliquid | 2025-03-19 | 20 | | Kraken | 2024-01-01 | Full | | Okex (OKX) | 2024-01-01 | 2000 | *** # Frequently Asked Questions **What are basis points in this context?** * One basis point is 0.01%. So 100bps means 1% away from the best-bid/best-ask price. The endpoint tracks liquidity depth at various bps levels. **Why is this useful during volatile periods?** * Order book depth gives a more complete view of where liquidity sits, allowing traders to anticipate price impact or dislocation. **What unit is the liquidity expressed in?** * Depth at the different basis point levels is expressed in the unit of a particular exchange/instrument. *** # Order Book Pressure Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/order-book-pressure # Definition Order Book Pressure is a market sentiment metric that quantifies the imbalance between buy-side and sell-side liquidity. It’s calculated as: \`Order\_Book\_Pressure = (bid depth βˆ’ ask depth)\`\` A positive value suggests stronger demand (buying pressure), while a negative value implies stronger supply (selling pressure). *** # Details Order Book Pressure helps traders and analysts gauge the aggressiveness of bids versus offers (asks) in real time. This metric is especially useful during volatile market events, offering insight into short-term sentiment and potential directional bias. The calculation uses visible volume in the order book at a given moment, not executed trades. It reflects intent to trade, which can be a leading indicator of market moves. *** # API Endpoint [/derivatives-analytics-order-book-pressure](/http/analytics/derivatives/depth-pressure) *** # Availability We cover all instruments on major exchanges like Binance, Deribit, OKX (Okex) and more. Please use the information endpoint to find all coverage and exact instruments. | Exchange | History | Depth Order Count | | :---------- | :-------------------------- | :---------------- | | Arkham | 2025-08-10 (end 2026-02-16) | Full | | Binance | 2024-01-01 | 1000 | | Bitmex | 2024-01-01 | Full | | Bybit | 2024-01-01 | 500 | | Deribit | 2024-01-01 | Full | | Hyperliquid | 2025-03-19 | 20 | | Kraken | 2024-01-01 | Full | | Okex (OKX) | 2024-01-01 | 2000 | *** # Frequently Asked Questions **How often is this data updated?** * Data is sampled at regular intervals (e.g., 1-minute), depending on the query. **Can I use this to predict price movements?** * While not predictive on its own, persistent pressure in one direction often precedes price continuation or reversal, especially when confirmed by other indicators. # Put Call Trades Distribution Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/put-calls-trades-distribution # Definition The Put Call Trades Distribution endpoint aggregates the total volume by option instruments for selected exchanges and currency types. It provides insights into the distribution of trades between put and call options. The data includes option premiums, representing the total sum of premiums paid for options, and contract counts, which reflect the raw number of contracts traded. Notional volumes are also included, representing the total underlying volumes, calculated based on the option’s underlying asset. For example, a 1 BTC option would represent a notional value equivalent to the current BTC price, regardless of the option's moneyness. *** # Details The Put Call Trades Distribution endpoint provides the following data fields: * Contracts Bought: * Call options: Total number of call contracts bought. * Put options: Total number of put contracts bought * Contracts Sold: * Call options: Total number of call contracts sold. * Put options: Total number of put contracts sold. * Premiums Bought: * Call options: Total premium paid for call contracts bought. * Put options: Total premium paid for put contracts bought. * Premiums Sold: * Call options: Total premium received for call contracts sold. * Put options: Total premium received for put contracts sold. * Exchange Direction: * Provides the adjusted totals for contracts and premiums bought and sold, based on exchange direction. *** # API Endpoints [/Put Call Trades Distribution](/http/analytics/derivatives/put-call-trades-distribution) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | --------------------- | | Binance | 2025-03-07 | Tick-Level Aggregated | | Deribit | 2019-04-01 | Tick-Level Aggregated | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Tick-Level Aggregated | *** # Frequently Asked Questions **What is the significance of notional volumes in the Put-Call Trades Distribution data?** * Notional volumes provide a representation of the total value of the underlying asset in option trades, giving a clearer picture of the market’s size and the relative importance of different trades, beyond just the number of contracts traded. *** # Seasonality: Volatility Day of Week / Month of Year Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/seasonality # Definition The **Realized Volatility Seasonality** metric provides insights into the average realized volatility of a cryptocurrency over a specified historical date range, grouped by either **day of the week** or **month of the year**. This metric enables the identification of seasonal patterns in market volatility and highlights how volatility fluctuates over time based on recurring temporal factors. Such seasonality-based analysis is valuable for assessing market behavior trends and for informing strategic trading decisions, portfolio management, and risk modeling. *** # Details Two endpoints are available: * **Volatility by Day of the Week** * **Volatility by Month of the Year** Each aggregates historical realized volatility observations by time period to compute the average volatility corresponding to each day or month. *** # API Endpoints [/Seasonality: Volatility Day of Week](/http/analytics/derivatives/seasonality:-volatility-day-of-week) [/Seasonality: Volatility Month of the Year](/http/analytics/derivatives/seasonality:-volatility-month-of-the-year) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ----------------- | | Binance | 2024-07-25 | Daily and Monthly | | GDAX | 2016-01-01 | Daily and Monthly | *** # Frequently Asked Questions **How does grouping realized volatility by day or month support market analysis?** * Aggregating volatility by day of the week or month of the year enables detection of consistent seasonal trends. These insights can be used to identify predictable patterns in market behavior, offering a statistical basis for timing strategies and volatility-adjusted portfolio decisions. *** # Term Structure Constant and Floating Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/term-structure # Definition The "Term Structure" endpoints display the at-the-money (ATM) implied volatility for both active maturities (floating) and constant maturities. In addition to the ATM term structure implied volatility, these endpoints also include the forward volatility calculation. *** # Details **Floating Term Structure:** * Displays the ATM implied volatility for active option maturities, i.e., the actual expiration dates of the options. * This reflects the current market's view of volatility across different time horizons. * Floating term structure allows for analysis of the shape and slope of the volatility curve based on market conditions. The calculation for forward volatility, or the differential IV between any two expiration cycles, is as follows:`Forward IV = √[ (ΞΈΒ²T - σ²t) / (T -t)]` ΞΈΒ² = Longer-dated option variance σ² = Shorter dated option variance T = time until expiration of the longer-dated option t = time until expiration of the shorter-dated option Using forward IV, a trader can gauge the most expensive portion of the term structure. **Constant Maturity Term Structure:** * Displays the ATM implied volatility for constant time-to-expiration (DTE) values, such as 30 days, 60 days, 90 days, etc. * This allows for a more standardized comparison of volatility across different periods, as the maturities are fixed. * Constant maturity term structure can be useful for analyzing the overall term structure and identifying potential mispricing opportunities. *** # API Endpoints [/Term Structures Constant](/http/analytics/derivatives/term-structures-constant) [/Term Structures Floating](/http/analytics/derivatives/term-structures-floating) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | ----------- | | Binance | 2025-03-08 | Minutely | | Deribit | 2019-04-01 | Minutely | | Lyra, Thalex, OKEx (OKX), Bybit | 2024-05-01 | Minutely | *** *** # Term Structure Richness - Deribit Only Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/term-structure-richness # Definition The β€œTerm Structure Richness” endpoint is the relative level of the Contango or Backwardation shape. The metric represents the difference between the implied volatility of two options with the same delta, but different expiration dates. It also provides insight into the relative expensiveness or cheapness of options at different maturities within the volatility term structure. *** # Details The term structure richness calculation is as follows: `Term Structure Richness = Average ATM IV Ratio of [7dte/30dte, 7dte/60dte, 7dte/90dte, 7dte/180dte, 30dte/60dte, 30dte/90dte, 30dte/180dte, 60dte/90dte, 60dte/180dte, 90dte/180dte]` The term structure richness metric can be interpreted as: 1. Les than 1.00 Value: "Contango" The longer-dated option is relatively more expensive (or "richer") compared to the shorter-dated option. 2. More than 1.00 Value: "Backwardation" The shorter-dated option is relatively more expensive (or "richer") compared to the longer-dated option. 3. 1.00 Value: The term structure is flat. For example, a reading of 1.00 would be a perfectly flat term structure - as measured by our method - while readings below/above represent Contango/Backwardation respectively. Using the term structure levels enables us to quantify how extended the term structure pricing currently is at any point in time. The calculation uses a weighted average of the 7-dte, 30-dte, 60-dte, 90-dte, and 180-dte at-the-money volatilities. *** # API Endpoints [/Term Structure Richness](/http/analytics/derivatives/term-structures-richness) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ------------- | | Deribit | 2019-04-01 | Hourly, Daily | *** *** # Top Trades Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/top-trades # Definition This feature provides detailed information on the most significant trades, including both on-screen and blocked trades. In addition to standard trade data, the endpoint offers proprietary insights that enhance the ability to analyze market flow. Key features include the\*\*Amberdata Direction \*\* metric, which identifies the true initiator of a trade, and the **Delta Hedge** indicator, which highlights block trades that contain a futures leg. Pre-trade and post-trade order book data are also included to offer a comprehensive view of market conditions around the trade. *** # Details * **Amberdata Direction:** A proprietary metric developed to accurately gauge the true initiator of a trade, offering deeper insight into market sentiment. * **Delta Hedge**: Identifies block trades that include a futures leg, providing valuable information on hedging strategies. * **Pre and Post Order Book Data**: Columns displaying order book conditions before and after the trade, enabling analysis of market impact and price movement. *** # API Endpoints [/Top Trades](/http/analytics/derivatives/top-trades) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | ----------- | | Binance | 2025-03-07 | Tick-level | | Deribit | 2019-04-01 | Tick-level | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Tick-level | *** # Frequently Asked Questions **What makes the "Top Trades" endpoint unique?** * This endpoint includes proprietary metrics such as "Amberdata Direction," which identifies the true trade initiator, and the "Delta Hedge" highlight for block trades containing futures legs. These features provide a deeper understanding of market flow beyond standard trade data. *** # Decorated Trades Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/decorated-trades # Definition The **Decorated Trades** feature provides a comprehensive view of options trades for ETFs and crypto-related equities, enriched with detailed data that goes beyond raw trade information. It includes pre-trade and post-trade Best Bid and Offer (BBO) data, enabling users to analyze trades in the context of market conditions at the time. This endpoint captures traded prices, sizes, and implied volatilities, comparing them with the best bid and ask prices and sizes. Additionally, it incorporates underlying index or spot prices at the time of the trade, pre-trade and post-trade open interest, and the impact of the trade on open interest levels. The enriched data set supports the development of proprietary heuristics to evaluate each trade from the taker’s perspective, assuming that dealers act as passive counterparties. In contrast, **Undecorated Trades** are raw trade data that lack integration with Level 1 quote data due to the unavailability of such information at the time of the trade. This distinction highlights the added value of decorated trade data for in-depth analysis. *** # Details The \*\*Decorated Trades \*\*endpoint provides the following data fields for a detailed analysis of options trades for ETFs and crypto-related equities: * **Exchange Information**: The platform or exchange where the trade occurred. * **Timestamps**: Precise time of the trade. * **Trade ID**: A unique identifier for each trade. * **Instrument Details**: Information about the traded option, including strike price, expiration, and type (call/put). * **Trade Characteristics**: Traded price, size, and implied volatility. * **24-Hour Metrics**: Volume and price changes over the past 24 hours. * **Pre-Trade BBO Data**: Best bid and offer prices and sizes before the trade. * **Post-Trade BBO Data**: Best bid and offer prices and sizes after the trade. * **Option Greeks**: Delta, Gamma, Theta, Vega, and Rho values associated with the traded option. * **Open Interest**: The number of outstanding contracts before and after the trade, along with the trade's impact on open interest. * **Directional Indicators**: Metrics indicating whether the trade was buyer- or seller-initiated. # API Endpoints [/TradFi Decorated Trades](/http/analytics/derivatives/tradfi-decorated-trades) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # Frequently Asked Questions *** # TradFi Delta Surfaces Constant and Floating Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/delta-surfaces-constant-and-floating # Definition Delta Surfaces provide a three-dimensional visualization of delta values for ETFs and crypto-related equities options, mapped across various strike prices and expiration dates. These surfaces highlight how an option’s deltaβ€”its sensitivity to changes in the price of the underlying ETF or equityβ€”varies with respect to the asset’s price and time to expiration. The data is calculated using interpolated implied volatility derived from exchange reference prices ("marks"), offering valuable insights into delta dynamics. Two types of delta surfaces are available: * **Constant Maturity Delta Surface**: Displays delta values for fixed time horizons, allowing standardized analysis regardless of actual expiration dates. * **Floating Delta Surface**: Represents delta values corresponding to the actual expiration dates of the options. *** # Details For a target delta value, such as βˆ†25, the process involves identifying the nearest inside and outside deltas around the target. For instance, if βˆ†28 and βˆ†22 are the closest values, the mark implied volatility is converted into variance, linearly interpolated, and then reconverted into volatility to achieve the desired target value. * Constant Maturity Analysis: This approach performs the same calculations across maturities to align with a specified constant "days-to-expiration" (DTE) value, ensuring consistency in time horizon comparisons. * Target Delta or DTE Requirements: To calculate a target delta or DTE value, both an inside and an outside data point must be available. If no outside point exists, the target value is returned as null. For example, if the smallest delta value in a given options chain is βˆ†7 and no value smaller than βˆ†5 exists, the target βˆ†5 value cannot be calculated and is therefore returned as null. # API Endpoints [/TradFi Delta Surfaces Constant](/http/analytics/derivatives/tradfi-delta-surfaces-constant) [/TradFi Delta Surfaces Floating](/http/analytics/derivatives/tradfi-delta-surfaces-floating) *** # Availability | Coverage | Start Date | Granularity | | ------------------------------------------------------------------------------------------------------------------- | ---------- | ----------- | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # TradFi Implied vs Realized Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/implied-vs-realized # Definition The **Implied vs Realized Volatility** endpoint provides a comparison between the implied volatility and realized volatility of ETFs or crypto-related equities, focusing on the underlying index price or spot value. This analysis is vital for understanding the divergence between market expectations (implied volatility) and historical price movements (realized volatility). The endpoint calculates close-to-close realized volatility using intraday data, typically for 7-day and 30-day periods. It also returns at-the-money (ATM) implied volatility for select constant maturities, such as 7, 30, 60, 90, and 180 days to expiration (DTE), offering insights across various time horizons. *** # Details Realized Volatility Calculation: * This feature calculates close-to-close realized volatility using the underlying index or spot price for ETFs and crypto-related equities. * Metrics for 7-day and 30-day realized volatility are provided, capturing short-term historical price fluctuations. * Realized volatility represents the actual historical volatility observed in the market, offering insights into past price behavior. Implied Volatility Data: * The endpoint returns at-the-money (ATM) implied volatility for specified constant maturities, providing a forward-looking perspective on expected market movement. * Constant maturities include 7, 30, 60, 90, and 180 days to expiration (DTE). * Implied volatility reflects the market's expectations for future price fluctuations, derived from option prices. # API Endpoints [/TradFi Implied (vs) Realized](/http/analytics/derivatives/tradfi-implied-vs-realized) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # Instruments Most Traded Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/instruments-most-traded # Definition The "Instruments Most Traded" endpoint aggregates total trading volume by option instruments associated with ETFs and crypto-related equities. It provides a clear snapshot of trading activity, highlighting which instruments are the most frequently traded. This data offers valuable insights into market trends, liquidity, and investor interest, helping traders and analysts focus on the most actively traded options.
# Details The "Instruments Most Traded" endpoint provides the following data fields to analyze trading activity for ETFs and crypto-related equities: * Exchange: The platform or exchange where the trading activity occurred. * Currency: The currency type associated with the trading activity. * Instrument: The specific option instrument being traded. * Contract Volume: The total number of contracts traded for the specified instrument. # API Endpoints [/TradFi Instruments Most Traded](/http/analytics/derivatives/tradfi-instruments-most-traded)
# Availability | Coverage | Start Date | Granularity | | :------------------------------------------------------------------------------------------------------------------ | :--------- | :---------- | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2021-12-01 | Daily |
# Frequently Asked Questions *** # Level 1 Quotes Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/level-1-quotes # Definition Level 1 Quotes represent the best bid and ask prices and sizes for a given financial instrument, such as ETFs or crypto-related equities, at a specific point in time. These quotes provide the most competitive prices at which an asset can be bought or sold. The Level 1 Quotes data includes the initial observation of these prices for every timestamp. Additionally, it may encompass associated metrics such as implied volatilities, greeks, and relevant underlying asset prices, forming the foundational data for a wide range of market analytics and trading strategies.
# Details Level 1 Quotes provide critical market data for traders and investors, offering insights into the pricing and liquidity of financial instruments such as ETFs or crypto-related equities. # API Endpoints [/TradFi Level 1 Quotes](/http/analytics/derivatives/tradfi-level-1-quotes)
# Availability | Coverage | Start Date | Granularity | | :------------------------------------------------------------------------------------------------------------------ | :--------- | :---------- | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITB, BITO, BITQ, BITX, BTC, COIN, CRCL, EETH, ETH, ETHU, GME, IBIT, MARA, MSTR, MSTU, MSTY, SATO, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # Frequently Asked Questions # Options Yields Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/options-yields # Definition The "Options Yields" endpoint calculates yields for two widely-used options strategies designed for ETFs and crypto-related equities: the Covered Call and the Cash Secured Put. These strategies offer a way to generate income while managing exposure to the underlying asset. * **Covered Call**: This strategy involves selling a call option while holding the underlying asset. The yield is calculated by comparing the proceeds from selling the call to the cost basis of the underlying asset. This approach allows investors to enhance returns when expecting minimal price movement in the underlying asset. * **Cash Secured Put**: This strategy entails selling a put option while maintaining sufficient cash to purchase the underlying asset if the option is exercised. The yield is determined by the premium received from selling the put relative to the cash set aside, providing a potential income stream while preparing for a favorable entry into the underlying asset. *** # Details **Covered Call:** * **Absolute Yield:** Calculated by dividing the proceeds from selling the call option by the initial investment in the underlying ETF or equity. * **Annualized Yield**: Derived by multiplying the Absolute Yield by a factor representing the number of minutes in a year (525,600) divided by the minutes remaining until the option expires. **Cash Secured Put:** * **Absolute Yield**: Determined by dividing the proceeds from selling the put option by the initial cash balance reserved to secure the position. * **Annualized Yield**: Calculated by multiplying the Absolute Yield by a factor representing the number of minutes in a year (525,600) divided by the minutes left until the option # API Endpoints [/TradFi Option Yields](/http/analytics/derivatives/tradfi-options-yields) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** *** # Term Structure Constant Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/term-structure-constant # Definition The **Term Structure Constant** endpoint displays the at-the-money (ATM) implied volatility for fixed, standardized maturities, regardless of the actual expiration dates of the options for ETFs and crypto-related equities. This standardization allows for consistent comparisons across different assets and time horizons. *** # Details * Displays at-the-money (ATM) implied volatility for fixed, standardized time-to-expiration (DTE) values, such as 30 days, 60 days, 90 days, and more. * Enables standardized comparisons of volatility across different time horizons, as the maturities remain constant regardless of actual expiration dates. * Useful for analyzing the overall term structure of implied volatility and identifying potential mispricing or arbitrage opportunities in ETFs and crypto-related equities options markets. # API Endpoints [/TradFi Term Structures Constant](/http/analytics/derivatives/tradfi-term-structures-constant) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # Realized Volatility (Close-to-Close) Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/tradfi-realized-vol # Definition Realized volatility is a measure of the actual price fluctuations of a financial asset, such as ETFs or crypto-related equities, over a specified period based on historical data. It quantifies the degree to which the asset's price has changed over a set number of past trading sessions. This metric is commonly calculated using closing prices, with variations that may include methods like the Parkinson method, which captures volatility by considering the range of price movements. For ETFs and equities, realized volatility offers critical insights into historical market behavior, enabling portfolio managers and analysts to evaluate past price stability and assess potential risk in their investment strategies. *** # Details For realized volatility, the data includes 30-day, 90-day, and 180-day Parkinson realized volatility metrics calculated for the primary ETF or crypto-related equity specified in the query. *** # API Endpoints [/markets/derivatives/analytics/realized-volatility/tradfi](/http/analytics/derivatives/tradfi-realized-volatility-close-to-close) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # TradFi Volatility Cones Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/volatility-cones # Definition Volatility Cones provide a visualization of the percentile distribution of realized volatility for a specific ETF or crypto-related equity across multiple measurement windows, relative to a selected end date. This tool enables investors and analysts to examine how historical volatility has evolved over different time frames and evaluate potential future volatility ranges. By analyzing these cones, users can identify patterns and trends in volatility behavior, supporting more informed risk management strategies and enhancing decision-making in portfolio construction and trading activities. *** # Details This endpoint provides a detailed percentile distribution of realized volatility for a specified asset, such as an ETF or crypto-related equity. The distribution spans multiple measurement windows, enabling comprehensive analysis of volatility trends over various time frames. Results include metrics such as the minimum, maximum, and median realized volatility, offering insights into the range and central tendency of historical volatility *** # API Endpoints [/markets/derivatives/analytics/realized-volatility/cones/tradfi](/http/analytics/derivatives/tradfi-volatility-cones) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | # TradFi Volatility Metrics Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/tradfi/volatility-metrics # Definition The **Volatility Metrics** endpoint provides a 24-hour snapshot of key changes in the options volatility surface for ETFs and crypto-related equities between two specified timestamps. This data enables traders and analysts to quickly assess significant shifts in the options market landscape, such as changes in implied volatility levels or structural movements in the volatility surface, facilitating timely decision-making and strategy adjustments. *** # Details The \*\*Volatility Metrics \*\*endpoint provides key data points capturing changes in the options volatility surface for ETFs and crypto-related equities, including: * **Underlying Price Change:** The difference in the price of the underlying ETF or equity between the two specified timestamps. * **At-the-Money (ATM) Volatility Change**: The change in the implied volatility of at-the-money options, reflecting shifts in market expectations for future price movements. * **Risk-Reversal Change**: The change in the volatility difference between out-of-the-money (OTM) call options and OTM put options with the same delta, offering insights into market sentiment and skew. * **Butterfly Value Change**: The change in the implied volatility of a butterfly strategy involving a long ATM option, short two OTM options with the same delta, and long two OTM options with a higher delta, capturing shifts in volatility smile dynamics. *** # API Endpoints [/TradFi Volatility Metrics (24 hr)](/http/analytics/derivatives/tradfi-volatility-metrics-24-hr) *** # Availability | Coverage | Start Date | Granularity | | ---------------------------------------------------------------------------- | ---------- | ----------- | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2024-11-01 | 5 min | | BITX, BITO, COIN, EETH, ETHU, MARA, MSTR, MSTU, SATO, IBIT, SBET, BMNR, ETHA | 2021-12-01 | Daily | *** # Volatility Cones Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volatility-cones # Definition Volatility Cones provide a visualization of the percentile distribution of realized volatility for a specific spot trading pair across multiple measurement windows, relative to a selected end date. This data allows investors and analysts to observe how historical volatility has varied over different time frames and assess the potential range of future volatility. By analyzing these cones, users can identify patterns and trends in volatility behavior, which can inform risk management strategies and enhance decision-making in trading and portfolio management. *** # Details Using this Amberdata endpoint for derivatives realized volatility cones provides a detailed percentile distribution of realized volatility for a specific spot trading pair, such as BTC/USD on the GDAX exchange. This distribution is available across multiple measurement windows, allowing for a comprehensive analysis of volatility trends over different time frames. For example, a query result could show the 180-day realized volatility is approximately 57.86%, with a minimum of 39.12% and a maximum of 112.16%. The 50th percentile (median) volatility for this period is 69.90%, indicating that half of the observed volatility values fall below this level. Again, this is an example of what the data can show. *** # API Endpoints [/Volatility Cones](/http/analytics/derivatives/volatility-cones) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ----------- | | Binance | 2024-07-25 | Daily | | GDAX | 2016-01-01 | Daily | *** # Frequently Asked Questions **How can volatility cone data from Amberdata be used to understand the historical behavior of a cryptocurrency's price movements over different time frames?** * Volatility cones provide insights into the historical distribution of realized volatility for a specific trading pair across multiple measurement windows. By examining these cones through the Amberdata endpoint response, users can gain a deeper understanding of how a cryptocurrency's price volatility has evolved, helping them to identify patterns and trends that may influence future market behavior. *** # Volatility Index and Volatility Index Decorated Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volatility-index # Definition The "Volatility Index" is a VIX-like implied volatility index calculation maintained by Deribit for the Bitcoin (BTC) and Ethereum (ETH) cryptocurrency markets. It serves as a benchmark for the market's expectation of 30-day volatility in the underlying asset. [![Watch the video](https://img.youtube.com/vi/4LMvh-ZhrL8/maxresdefault.jpg)](https://youtu.be/4LMvh-ZhrL8) *** # Details The Volatility Index is designed to reflect a 30-day constant expiration, similar to the CBOE Volatility Index (VIX) for traditional equity markets. The index is calculated based on the weighted average of out-of-the-money (OTM) BTC or ETH option prices, capturing the market's consensus on near-term future volatility. The weighting scheme and other details of the calculation can be found here: [https://insights.deribit.com/exchange-updates/dvol-deribit-volatility-index-vix-index-for-comparison/](https://insights.deribit.com/exchange-updates/dvol-deribit-volatility-index-vix-index-for-comparison/) In addition to the standard Volatility Index, we also provide a "Volatility Index Decorated" endpoint. This version of the index incorporates additional metadata to enhance the analysis and interpretation of the volatility index. *** # API Endpoints [/Volatility Index](/http/analytics/derivatives/volatility-index) [/Volatility Index Decorated](/http/analytics/derivatives/volatility-index-decorated) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | -------- | ----------------------- | ----------- | | Deribit | 2021-05-01 | Minutely | *** *** # Volatility Metrics Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volatility-metrics # Definition The "Volatility Metrics" endpoint provides users with a quick 24-hour snapshot of the key changes in the options volatility surface between two given timestamps. This allows for a quick assessment of the important shifts in the options market landscape. *** # Details Volatility Metrics returns several important metrics that capture the changes in the options volatility surface, including: **Underlying Price Change:** * The change in the price of the underlying asset (e.g., BTC, ETH) between the two timestamps. **At-the-Money (ATM) Volatility Change:** * The change in the implied volatility of the at-the-money options. **Risk-Reversal Change:** * The change in the volatility difference between out-of-the-money (OTM) call options and OTM put options with the same delta. **Butterfly Value Change:** * The change in the implied volatility of an options strategy that involves a long position in the ATM option, a short position in two OTM options (one call, one put) with the same delta, and a long position in two OTM options (one call, one put) with a higher delta. *** # API Endpoints [/Volatility Metrics](/http/analytics/derivatives/volatility-metrics-24-hr) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------- | ------------------------ | ----------- | | Binance | 2025-03-07 | Minutely | | Deribit | 2019-04-01 to 2021-09-01 | Hourly | | Deribit | 2021-09-01 | Minutely | | Bybit, Lyra, Thalex | 2024-06-01 | Minutely | | OKEx (OKX) | 2021-12-16 to 2024-05-01 | Daily | | OKEx (OKX) | 2024-05-01 | Minutely | *** *** # Volatility Ratio Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volatility-ratio # Definition The **Monthly versus Daily Volatility Ratio** is a measure that compares the realized volatility of a cryptocurrency asset over a monthly period to its daily realized volatility. This ratio helps investors assess how volatility changes when observed over longer versus shorter time frames. By utilizing this data, users can access precise calculations of this ratio, offering valuable insights into the asset's volatility patterns and risk characteristics. This metric is particularly useful for understanding the stability of an asset's price movements and making informed decisions in portfolio management and risk assessment. *** # Details This endpoint returns the relationship/comparison of Parkinson realized volatility calculation using one monthly calculation versus 30 daily calculations. The reason these calculations might differ is due to mean-reversion, intra-month volatility, and trending markets. *** # API Endpoints [/Monthly versus Daily Volatility Ratio](/http/analytics/derivatives/monthly-versus-daily-volatility-ratio) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | --------------- | ----------------------- | ----------- | | Binance | 2024-09-01 | Daily | | GDAX (Coinbase) | 2016-01-01 | Daily | *** # Frequently Asked Questions **How can the Monthly versus Daily Volatility Ratio from Amberdata help investors assess the stability of a cryptocurrency's price movements over different time frames?** * Investors and analysts use this metric to understand how volatility scales when comparing daily to monthly periods. By leveraging this Amberdata endpoint, users can gain insights into whether a cryptocurrency's volatility is consistent or varies significantly across these time frames, aiding in risk assessment and strategic decision-making for portfolio management. *** # Volume Aggregates Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volume-aggregates # Definition The Volume Aggregates endpoint provides the total traded options volume for a selected exchange and underlying currency. The volume data is divided into two categories: on-screen exchange volume and 3rd party **block trades** from platforms such as Paradigm, GreeksLive, etc. *** # Details The Volume Aggregates endpoint provides the following data fields: * **Exchange**: The trading platform where the data was collected (e.g., Deribit). * **Currency**: The currency of the underlying asset (e.g., BTC). * **Timestamp**: The date and time of the data snapshot. * **Contract Volume On-Screen**: The total volume of contracts traded directly on the exchange's order book. * **Contract Volume Blocked**: The total volume of contracts traded through 3rd party platforms (block trades). * **Premium Volume On-Screen**: The total premium amount for contracts traded on-screen. * **Premium Volume Blocked**: The total premium amount for contracts traded through block trades. * **Notional Volume On-Screen**: The total notional value of contracts traded on-screen. * **Notional Volume Blocked**: The total notional value of contracts traded through block trades. *** # API Endpoints [/Volume Aggregates](/http/analytics/derivatives/volume-aggregates) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------------------------- | ----------------------- | ----------------------- | | Binance | 2025-03-07 | Daily, Hourly, Minutely | | Deribit | 2019-04-01 | Daily, Hourly, Minutely | | Bybit, Lyra, Thalex, OKEx (OKX) | 2024-06-01 | Daily, Hourly, Minutely | *** # Frequently Asked Questions **What is included in "Contract Volume On-Screen" and "Contract Volume Blocked"?** * \_Contract Volume On-Screen \_includes trades executed directly on the exchange, while \_Contract Volume Blocked \_covers trades executed through 3rd party platforms. **How are "Premium Volume On-Screen" and "Premium Volume Blocked" different?** * *Premium Volume On-Screen* is the total premium for contracts traded on the exchange, and *Premium Volume Blocked* is for contracts traded through block trades. **What does "Notional Volume" represent?** * *Notional Volume* refers to the total value of the contracts traded, both on-screen and through block trades. *** # Trading Volumes Source: https://docs.amberdata.io/data-dictionary/analytics/derivatives/volumes-add # Definition Volume provides an overview of the trading activity for futures and perpetual contracts of a cryptocurrency over the past day. It shows how much has been traded in both USD and the cryptocurrency itself, helping traders understand the level of market activity and liquidity. *** # Details The Rolling 24-Hour Volume measures the total trading volume for futures and perpetual contracts of an underlying asset within the last 24 hours. This data is presented in millions of USD and in units of the underlying cryptocurrency. By analyzing this metric, traders and analysts can assess market activity and liquidity, gaining insights into trading intensity and potential market dynamics. *** # API Endpoints [/Volumes](/http/analytics/derivatives/volumes) *** # Availability | Exchange | Start Date (YYYY-MM-DD) | Granularity | | ------------- | ----------------------- | ----------- | | All Exchanges | 2022-08-01 | Hourly | *** # Frequently Asked Questions **How does trading volume impact the liquidity and price movements in futures and perpetual markets?** * Generally speaking, trading volume is a crucial indicator of market activity and liquidity. High trading volume in futures and perpetual markets typically signals strong interest and participation, which can lead to more stable prices and easier execution of trades. Conversely, low volume might indicate less liquidity, potentially resulting in larger price swings and increased slippage. Understanding the relationship between volume and market dynamics helps traders make informed decisions about entering or exiting positions. *** # DeFi Lending Source: https://docs.amberdata.io/data-dictionary/analytics/lending-market-insights Datasets are available via REST API, Databricks, and Snowflake. *** # Description The DeFi Lending metrics are split between stablecoins, protocols, and networks. This dashboard on Amberdata Intelligence is restricted to three months of historical data and includes visualizations spanning across Avalanche, Arbitrum, Ethereum, Optimism, and Polygon in addition to all lending activity across Aave v2, Aave v3, Compound v2, Compound v3, and MakerDAO. *** # Use Case **Traders** can use this data to gain a perspective on potential collateral risks and high flow of funds into or out of DeFi Lending protocols and monitor the activity of specific protocols on multiple networks. **Researchers** can use these visualizations to gain a thorough understanding of the impacts of DeFi Lending on token prices and evaluate how market cycles impact borrowing activity or liquidations. **Analysts** can use these datasets for a variety of purposes, including: * Monitoring deposit and withdrawal volumes for an indication of additional liquidity risks or support * Evaluating borrow and repayment volumes for indications of wider liquidity or a large flow of funds across protocols and networks. *** # Methodology These dashboards utilize Amberdata’s DeFi Data endpoints: [Metrics](/docs/blockchain/lending-metrics) and [Stablecoin Metrics](/docs/blockchain/lending-stablecoin-metrics). *** # Liquid Staking Source: https://docs.amberdata.io/data-dictionary/analytics/liquid-staking *** # Description **Ethereum Liquid Staking Token Dashboard** highlights Ethereum-based liquid staking tokens and their associated yields and supply. Coverage includes: * **Rocket Pool**: rETH * **Lido**: stETH * **Coinbase**: cbETH * **Binance**: wbETH * **Swell**: swETH * **Ankr**: ankrETH * **LiquidCollective**: lsETH. *** # Use Cases \*\*Traders: \*\*APY on liquid staking tokens is a key indicator for traders, as it impacts the profitability of short-term trading strategies. A high APY may signal an opportunity to buy and hold the token to benefit from staking rewards alongside potential price appreciation. Conversely, a declining APY might encourage traders to sell to avoid diminishing returns. Generally, higher yields also imply increased risk. \*\*Researchers: \*\*Blockchain researchers study the economic incentives and behavioral trends within staking ecosystems. APY serves as a vital data point, reflecting how attractive staking mechanisms are to users. By analyzing APY trends, researchers can assess the health, stability, and investor confidence of staking protocols, providing insights into adoption dynamics and protocol success. \*\*Analysts: \*\*Analysts use APY metrics to gauge the robustness of staking systems. A stable or rising APY often signals a healthy protocol and may inform positive investment recommendations. Additionally, analysts compare staking token APYs against traditional financial instruments and other crypto assets to shape portfolio and client investment strategies. *** # Methodology **APY Calculation**\ Each liquid staking token (LST) protocol emits events that provide exchange rate data linking the LST to its underlying ETH peg. The APY is calculated by comparing the exchange rate ratio from yesterday to the current ratio and annualizing the yield using the formula: `APY= \left(\frac{\text{current_ratio}}{\text{yesterday_ratio}} - 1\right) \times 365 \times 100` To smooth short-term fluctuations, a rolling average APY over 7-day and 30-day windows is calculated: `RollingΒ APY=AVG(apr)Β OVERΒ (ORDERΒ BYΒ dateΒ ASCΒ ROWSΒ BETWEENΒ 6Β PRECEDINGΒ ANDΒ CURRENTΒ ROW)` *** ### Relevant Contract Events for LST APY Calculation | Token | Event Name | Event Signature (Topic 0) | | :------ | :---------------------- | :----------------------------------------------------------------- | | rETH | balance\_updated | 0x7bbbb137fdad433d6168b1c75c714c72b8abe8d07460f0c0b433063e7bf1f394 | | ankrETH | ratio\_updated | 0xb779c97cee7508e970bdead8c3ef0bd16f8c63dbba28fe88f7c7a56722fc564d | | cbETH | exchange\_rate\_updated | 0x0b4e9390054347e2a16d95fd8376311b0d2deedecba526e9742bcaa40b059f0b | | lsETH | rewards\_earned | 0x3d1669e813a9845c288f0e1f642a4343a451103b87886d12de37e63b39bbd942 | | stETH | token\_rebase | 0xff08c3ef606d198e316ef5b822193c489965899eb4e3c248cea1a4626c3eda50 | | swETH | token\_reprice | 0xf0e4379b3fd6b436bf73f47761c746a33d02bbd47835cbd8050b130fb2c6db2e | | wbETH | exchange\_rate\_updated | 0x0b4e9390054347e2a16d95fd8376311b0d2deedecba526e9742bcaa40b059f0b | # Re-Staking: EigenLayer Source: https://docs.amberdata.io/data-dictionary/analytics/liquid-staking-copy *** # Description EigenLayer is a protocol that has introduced **re-staking**, which allows users to use the security of Ethereum to secure other networks. This is done by bonding LST to the EigenLayer contract to secure other protocols. In exchange for re-staking, re-stakers will receive protocol fees and rewards for providing this security. *** # Use Case \*\*Traders: \*\*Re-staking Ethereum allows traders the ability to retain liquidity while at the same time speculating on this entire new crypto primitive. Re-staking Ethereum aligns with their strategic approach of harnessing various investment tools to optimize profit potential, reinforcing their position in the ever-evolving digital asset landscape. \*\*Researchers: \*\*Researchers can analyze the economic incentives driving participants to engage in re-staking, exploring its potential impact on Ethereum's ecosystem dynamics and long-term sustainability. Additionally, they use this data to understand the incentive structure, potential benefits, and risks of the entire re-staking ecosystem. **Analysts:** It is important for analysts to understand staking rewards, slashing conditions, and network participation rates to gauge the potential returns and associated risks of engaging in re-staking activities. Furthermore, analysts monitor Ethereum's on-chain metrics and network health indicators to identify emerging trends and potential opportunities for optimizing staking strategies. *** # Methodology * **TVL:** Total Value Locked (TVL) for the protocol is calculated by summing all deposits and withdrawals into EigenLayer and multiplying the net token amounts by their respective market prices. TVL is reported both in native token quantities and USD value. * **Amount Staked (LST / Native ETH):** The daily total of Liquid Staking Tokens (LST) and native ETH deposited into EigenLayer contracts is calculated, along with the cumulative daily balance over time. * **Daily Depositors:** The count of unique wallet addresses depositing into EigenLayer contracts each day is tracked. * **Pod Deployed:** Every new pod creation event is recorded daily, and cumulative totals of pods deployed are maintained. * **LST Delegation to Operators:** Users staking on EigenLayer may delegate their LST to Operators who support Autonomous Validator Services (AVSs). Delegation volume (in ETH/LST) per operator is analyzed to identify the largest and most popular operators. * **Number of Stakers to Operators:** The total count of unique wallets delegating to each operator is tracked, helping to illustrate the distribution of staked ETH and the number of participants. * **AVS Overview:** Monitors deployed and created AVSs, providing insight into areas of focus and activity within the AVS ecosystem. * **Registered AVS:** Tracks operator events registering AVSs, allowing monitoring of which operators support which AVSs. *** # Liquid vs Illiquid Supply Source: https://docs.amberdata.io/data-dictionary/analytics/liquid-vs-illiquid-supply *** # Description Daily address balance metrics provide insights into the diversity of the network and changes to network adoption. * Balance changes represent every change in token balance for every address * Address balances contain a daily list of addresses and the total balance of tokens they hold * BTC balance buckets contain an aggregation of the number of addresses and total number of tokens held by addresses with various balances (in 1e10 increments ranging from 0 and 0.000001 BTC to 10,000+ BTC) * USD balance buckets contain an aggregation of the number of addresses and total number of tokens held by addresses with various balances (in 1e10 increments ranging from 0 to \$10,000,000 USD) * Addresses in profit count the total number of addresses with an average token price (tokens are valued at the day they move to the address) greater than the end-of-day price, and the total number of tokens held by those addresses. * Liquid vs illiquid supply calculates the number of tokens held by addresses with a liquidity score in various ranges. The liquidity score is calculated as the ratio between outputs and inputs. The ranges are: * 0 - 0.25: The address is considered illiquid * 0.25 - 0.75: The address is considered liquid * 0.75 - 1: The address is considered highly liquid **Addresses in Profit:** This metric shows what percent of the total address space is in a profitable position, or the percentage of unique addresses whose assets have an average buy price that is lower than their current price. **Liquid vs Illiquid supply:** Understanding an asset's liquidity is crucial to understanding its market. If an asset is highly illiquid, it could indicate a bullish environment and strong HODLing sentiment. *** # Use Cases \*\*Traders \*\*can use these metrics to understand the shifts in network behaviors, as growth or decline in address balances, movement of liquid to illiquid balances, and growth or decrease of addresses in profits may help traders make more informed decisions on when to buy and when to sell. \*\*Analysts \*\*can use these metrics to support profitability and wallet metrics for their portfolios. **Researchers** can use these metrics to determine market trends and discover patterns in network behaviours. *** # Methodology The liquidity score for every address is calculated as the cumulative absolute sum of outputs divided by the cumulative sum of inputs. This ratio is considered the **liquidity score.** Every address will have a liquidity score every time its balance changes. * WHEN b.liquidity\_score \<= 0.25 THEN 'illiquid' * WHEN b.liquidity\_score \<= 0.75 THEN 'liquid' * ELSE 'highly liquid' *** # Market Cap vs Realized Cap Source: https://docs.amberdata.io/data-dictionary/analytics/market-cap-vs-realized-cap *** # Description Realized Capitalization (Realized Cap) represents the value of an asset based on the price at which it was last moved. This metric is available for both ETH and BTC, providing a comparison between traditional Market Cap and Realized Cap. *** # Use Cases Realized Cap serves as an alternative measure to Market Cap. While Market Cap reflects the total value of assets at the current price, Realized Cap reflects the value of all assets at the last price they moved. It can also be interpreted as the aggregate cost basis of all coins within a network, representing the cumulative value of all assets based on their last transaction price. Due to the calculation methodology, older assets have significant influence on Realized Cap because they were last moved at earlier, often lower prices. When older tokens move, their value is re-priced at the current price, potentially causing substantial shifts in Realized Cap. When Realized Cap exceeds Market Cap, the network is considered to be at an aggregate loss (out of profit). Conversely, when Realized Cap is lower than Market Cap, the network is in aggregate profit. *** # Methodology * **Market Cap** = Total supply Γ— Current price * **Realized Price** = Amount Γ— Price at time of last movement For UTXO-based assets like BTC, the calculation is straightforward since each output has a defined creation price at spend time. For account-based chains like ETH, the calculation is more complex. The methodology for ETH uses a Last In, First Out (LIFO) stack-based accounting model for determining the price of tokens, inspired by [Stack Coin Age model | Santiment Academy](https://academy.santiment.net/metrics/details/stack-coin-age-model/#account-based-blockchains). *** *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/market-insights Built for asset managers, researchers, analysts, and traders, [Amberdata Intelligence](https://intelligence.amberdata.com/) is a hub of institutional market dashboards developed with the most granular digital asset data available. The metrics and data used to make Amberdata Intelligence charts are updated daily and are available via REST API, AWS S3, Snowflake, and Databricks. Please refer to the individual pages below to find delivery methods for each dataset. # History Source: https://docs.amberdata.io/data-dictionary/analytics/market-insights-history All metrics unless otherwise stated are available via Databricks, and Snowflake. # Institutional Bitcoin Market Indicators | Metric | Dataset Start (YYYY-MM-DD) | | -------------------------------- | -------------------------- | | Balance Bucket Daily | 2012-01-01 | | HODL Net Position Change Daily | 2012-01-02 | | HODL Net Position Change Monthly | 2012-01-02 | | HODLed Coins Daily | 2012-01-01 | | Liveliness Daily | 2012-01-01 | | Miner Supply Mined Spent Daily | 2012-01-01 | | Coin Days Destroyed Daily | 2012-01-01 | | MVRV Daily | 2012-01-01 | | NUPL Daily | 2012-01-01 | | Price Moving Average | 2012-01-01 | | Puell Multiple Daily | 2012-01-01 | | Realized Cap Daily | 2012-01-01 | | Realized Price Daily | 2012-01-01 | | Reserve Risk Daily | 2012-01-01 | | Bitcoin Yardstick Daily | 2015-01-01 | | Liquid vs Illiquid Supply | 2009-01-03 | | Balance Buckets USD | 2012-01-01 | | Address Momentum Daily | 2009-01-03 | | Stock to Flow | 2010-01-03 | | Supply in Profit | 2012-01-01 | | HODL Waves | 2009-01-03 | # Institutional Ethereum Market Indicators | Metric | Dataset Start (YYYY-MM-DD) | | ---------------------------- | -------------------------- | | Stablecoin Issuance | 2017-11-28 | | Realized Cap | 2015-08-09 | | MVRV Daily | 2016-01-01 | | Realized Price | 2015-08-09 | | NUPL Daily | 2016-01-01 | | Price Moving Average | 2016-01-01 | | Balance Bucket Daily | 2015-07-30 | | Liquid/Illiquid Supply Daily | 2015-07-30 | | Address Momentum Daily | 2015-08-07 | | Address USD Balance Buckets | 2016-03-09 | # Ethereum Network Metrics | Metric | Dataset Start (YYYY-MM-DD) | | -------------------------- | -------------------------- | | Ethereum Supply | 2015-07-30 | | Active Ethereum Validators | 2020-11-03 | # USD Stablecoin Metrics | Token | Dataset Start (YYYY-MM-DD) | | ----- | -------------------------- | | DAI | 2019-11-13 | | FDUSD | 2023-05-26 | | FEI | 2021-04-03 | | FRAX | 2020-12-16 | | HUSD | 2019-07-20 | | LUSD | 2021-04-05 | | MIM | 2021-06-02 | | PYSUD | 2023-01-24 | | TYUSD | 2018-03-05 | | USDC | 2018-09-10 | | USDT | 2017-11-28 | # EUR Stablecoin Metrics | Dataset | Dataset Start (YYYY-MM-DD) | | ------------------- | -------------------------- | | Issuance | 2018-06-22 | | Circulating Supply | 2018-06-22 | | Market Cap | 2018-06-22 | | Transfers | 2018-06-22 | | Senders & Receivers | 2018-06-22 | | Velocity | 2018-06-22 | | Holders | 2018-06-22 | # Digital Commodities Stablecoin Metrics | Dataset | Dataset Start (YYYY-MM-DD) | | ------------------- | -------------------------- | | Issuance | 2018-03-23 | | Circulating Supply | 2018-03-23 | | Market Cap | 2018-03-23 | | Transfers | 2018-03-23 | | Senders & Receivers | 2018-03-23 | | Velocity | 2018-03-23 | | Holders | 2018-03-23 | # Treasury-Backed RWA | Treasury | Dataset Start (YYYY-MM-DD) | | ---------- | -------------------------- | | Backed | 2023-03-06 | | Blackrock | 2024-03-04 | | Hashnote | 2023-06-13 | | Maple | 2023-05-04 | | MatrixDock | 2023-01-18 | | Ondo | 2023-01-26 | | OpenEden | 2023-10-18 | | USTB | 2024-01-04 | # Digital Asset ETFs | Asset | Dataset Start (YYYY-MM-DD) | | ----- | -------------------------- | | BTC | 2024-01-11 | | ETH | 2024-07-24 | # Options Trading Overview | Dataset Start (YYYY-MM) | | ----------------------- | | 2019-04 | # Spot Trading Overview | Exchange | Dataset Start (YYYY-MM-DD) | | ----------- | -------------------------- | | Binance | 2017-07-13 | | Binance.US | 2019-09-17 | | Bitfinex | 2013-01-14 | | Bithumb | 2013-12-27 | | Bitstamp | 2011-08-18 | | Bybit | 2021-07-05 | | Coinbase | 2014-12-01 | | Gemini | 2015-10-08 | | HTX (Huobi) | 2019-01-31 | | Kraken | 2013-10-06 | | LMAX | 2018-02-15 | | MEXC | 2022-10-16 | | OKX | 2019-07-11 | | Poloniex | 2014-02-07 | # Liquid Staking and Re-Staking | Liquid Staking - APYs | Dataset Start (YYYY-MM-DD) | | --------------------- | -------------------------- | | wbETH | 2023-04-19 | | sweth | 2023-04-24 | | oETH | 2023-04-30 | | ankrETH | 2023-03-09 | | rETH | 2022-07-15 | | cbETH | 2022-07-16 | | stETH | 2022-09-01 | | lsETH | 2023-10-02 | | Liquid Staking - Supply | Dataset Start (YYYY-MM-DD) | | ----------------------- | -------------------------- | | wbETH | 2023-04-25 | | osETH | 2023-11-16 | | oETH | 2023-04-18 | | sfrxETH | 2023-10-06 | | swETH | 2023-04-18 | | ankrETH | 2020-11-20 | | rETH | 2021-10-02 | | mETH | 2023-10-10 | | cbETH | 2022-02-07 | | stETH | 2023-05-16 | | lsETH | 2023-06-02 | | Re-Staking Metrics | Dataset Start (YYYY-MM-DD) | | ---------------------------- | -------------------------- | | TVL | 2023-06-10 | | Native Staked ETH | 2023-06-10 | | TVL by asset | 2023-06-10 | | Depositors Daily | 2023-06-10 | | Daily Balance Change | 2023-06-10 | | EigenLayer - **All Metrics** | 2024-04-08 | # DeFi Lending | Protocol | Ethereum | Polygon | Arbitrum | Optimism | Avalanche | | ----------- | ---------- | ---------- | ---------- | ---------- | ---------- | | Aave v2 | 30-11-2020 | - | - | - | 04-10-2021 | | Aave v3 | 27-01-2023 | - | 15-03-2022 | 15-03-2022 | 12-03-2022 | | MakerDAO | 13-11-2019 | - | - | - | - | | Compound v2 | 07-05-2019 | - | - | - | - | | Compound v3 | 01-09-2022 | 07-03-2023 | - | - | - | Dates are shown in (DD-MM-YYYY). *** # Options Trading Source: https://docs.amberdata.io/data-dictionary/analytics/market-insights-options Note: This dataset is updated hourly and available via Databricks, and Snowflake. *** # Description This dashboard provides key aggregations of volume and open interest for the entire cryptocurrency options market as monitored by Amberdata. Currently, this includes Deribit, Okex, and Bybit, which together represent approximately 95% of the total crypto options market. All metrics on this page are expressed in nominal US dollar values. * **Volumes**: Volumes represent the nominal values traded in the last 24 hours. * **Open Interest**: Open interest represents the nominal values of open contracts. Typically, high volumes and high open interest indicate significant market activity and heightened volatility. For our full options analytics suite, please go to [Amberdata Derivatives](https://pro.amberdata.io/). *** # Use Case \*\*Researchers: \*\*This dataset enables comprehensive analysis of the evolving options market, a growing segment within the broader derivatives landscape, which remains largely dominated by futures. Researchers can track trends over time and across multiple assets and exchanges, allowing for the identification of structural patterns and market behavior. \*\*Analysts: \*\*For market participants seeking strategic insights, monitoring instruments with elevated open interest or trading volume may indicate areas of concentrated activity and liquidity. Such observations can inform positioning, risk assessment, and potential market inefficiencies. *** # Methodology Data is sourced from the specified endpoint, updated on an hourly basis, and aggregated from the fundamental unit of each instrument per exchange. Each exchange defines its own technical specifications for quoting instrumentsβ€”some denominate values in native assets (e.g., BTC options on Deribit), while others use stablecoins (e.g., BTC options on Bybit quoted in USDC). To enable cross-exchange and cross-instrument comparison, contract values have been standardized to U.S. dollar equivalents. This normalization accounts for exchange-specific multipliers and contract structures, ensuring consistency across the dataset. *** # Spot Trading Source: https://docs.amberdata.io/data-dictionary/analytics/market-insights-spot-data Note: This dataset is updated daily and available via Market Data API only. *** # Description Spot trading metrics offer a detailed view of activity across centralized exchanges (CEXs), highlighting both platform-level and trading pair-level dynamics. The associated dashboards are organized into three thematic categories: exchange overviews, USD and stablecoin overviews, and frequently traded token overviews. These views collectively support the analysis of ongoing and historical trends in the spot market. Access via the AmberLens platform is limited to three months of historical data. *** # Use Case **Traders:** Spot trading metrics can be used to evaluate exchange-level trade histories, including market share by trading volume across exchanges and token categories. Frequently traded tokens are analyzed to assess their influence on overall market activity. Historical data on trading pairs supports the identification of momentum shifts, highlighting pairs gaining or losing market traction over time. \*\*Researchers: \*\*Researchers focused on market microstructure or the impact of external events can utilize spot trading metrics to assess shifts in trading activity across exchanges. The data supports correlation analyses with macroeconomic trends, token-specific developments, or regulatory events. **Analysts**: Market analysts often rely on trading volume and market share metrics to assess exchange performance, identify potential shifts in exchange profitability, or evaluate the impact of token listings and delistings. These insights also contribute to sentiment analysis within the broader centralized exchange ecosystem. *** # Methodology The dashboards are powered by Amberdata’s Market Data endpoints, specifically the **OHLCV** (Open, High, Low, Close, Volume) and **Metrics** APIs. Data is aggregated at regular intervals and normalized across exchanges to ensure consistency in comparative analysis. *** # Market Value: Realized Value (MVRV) Source: https://docs.amberdata.io/data-dictionary/analytics/market-value-realized-value-mvrv *** # Description The MVRV Z-Score measures the deviation between an asset’s market value and its realized value. It is commonly used to identify periods when the market may be overheated (overvalued) or undervalued relative to historical norms. Elevated Z-Scores often coincide with market tops, while suppressed scores may indicate potential market bottoms. This metric is available for both Bitcoin (BTC) and Ethereum (ETH). *** # Use Cases The MVRV Z-Score is a valuable tool for evaluating market cycles and assessing whether an asset is trading above or below its aggregated cost basis. It can assist in identifying overbought or oversold conditions, drawing comparisons between historical valuation extremes, and informing strategic decisions such as accumulating during undervalued phases or reducing exposure near potential peaks. *** # Methodology **MVRV Z-Score** = (Market Cap - Realized Cap) / Std(Market Cap) The standard deviation is computed cumulatively from the inception of the dataset to the present day, providing a dynamic normalization of the deviation between market and realized capitalization values. *** *** # Miner Position Index Source: https://docs.amberdata.io/data-dictionary/analytics/miner-position *** # Description The Miner Position Index (MPI) is the z-score ratio of miner outflows to the 365-day moving average. The MPI is an indicator of how much of the supply held by miners moved out as compared to the 365-day moving average of miner outflows. As the metric increases, miners are more involved in selling and sending their supply more than usual. As the metric decreases, miners are less involved in selling and sending their supply less than usual. *** # Use Case \*\*Traders \*\*can use this to evaluate increases in BTC supply from miners or a slower increase in supply from miners. \*\*Analysts \*\*can use this metric to evaluate how miners are positioning based on the market cycle. \*\*Researchers \*\*can use this metric to identify patterns in supply/demand during market peaks (such as ATHs). *** # Methodology **MPI** = Moving 365-day z-score (capitulation index) **Capitulation Index** = Sum(Miner Outflows) / 365 DMA\_Sum(Miner Outflows) *** # Frequently Asked Questions **How often is this chart updated?** * Daily. *** # Miner Supply Spent Source: https://docs.amberdata.io/data-dictionary/analytics/miner-supply-spent *** # Description **Percentage of Miner Supply Spent**, also referred to as **Miner Supply Sold**, represents the daily percentage of miner-held balances that have been spent or sold, rather than accumulated. This metric is used to monitor miner behavior, which can influence market supply dynamics. Bitcoin miners often liquidate holdings to cover operational expenses or distribute profits. As miner sell-offs increase, additional Bitcoin enters the market, potentially exerting downward pressure on prices. Miner behavior also serves as an indicator of network health. A larger, more active miner base contributes to decentralization. Accumulation by miners is generally considered a bullish signal, as it suggests delayed entry of those tokens into market circulation. *** # Use Case **Traders** can use this metric to sell ahead of miners. \*\*Analysts \*\*can track this metric to evaluate and compare the health of the network. \*\*Researchers \*\*can use this metric to identify correlations between miner activity and overall market sentiment. *** # Methodology **Percent of Miner Supply Sold** = Spent Tokens from Miners / Supply. *** # Frequently Asked Questions **How often is this chart updated?** * Daily. *** # Monthly HODL Net Position Change Source: https://docs.amberdata.io/data-dictionary/analytics/monthly-hodl-net-position-change *** # Description [Liveliness](https://medium.com/@tamas.blummer/liveliness-of-bitcoin-174001d016da) is the ratio between the sum of Bitcoin Days Destroyed and the sum of all Bitcoin Days Ever Created. It reflects investor behavior on the network, increasing as long-term holders liquidate positions and decreasing during accumulation phases. A high Liveliness indicates a higher rate of meaningful on-chain activity, whereas a lower Liveliness suggests that a greater portion of supply is inactive or being held. Liveliness approaches 1 if all coins move within a single block and trends toward 0 in a network where coins remain dormant aside from issuance. It provides insight into whether the network is primarily being used for transactions or long-term holding. The number of β€œLost or HODLed Bitcoins” can be derived by subtracting Liveliness from 1 and multiplying the result by t**he t**otal supply. This value tends to decrease during bull markets, when more coins are spent or traded, and increase during periods of low price volatility, when accumulation is more common. **HODLer Net Position Change** measures the net accumulation or distribution of Bitcoin by long-term holders. It reflects changes in the total balance of these holders over time. During bull markets, this metric tends to decline as long-term holders sell into rising prices. Conversely, it rises in bear markets or periods of consolidation, when these participants accumulate more Bitcoin. While **Liveliness** measures overall investor activity across the network, **HODLer Net Position Change** focuses specifically on behavior among large, long-term holders. *** # Use Case **Traders** use these metrics by staying ahead of whale activity, which can dramatically shift token prices. **Analysts** use these metrics to identify the stage of the market. \*\*Researchers \*\*use these metrics to find patterns of whale activity to token prices, and to find measures of network activity (liveliness) to adoption rates. *** # Methodology **Coin Days Created (CDC)** = Cumulative Sum of (Issuance \* Reward Days Created) **Liveliness** = SUM(Coin Days Destroyed) / SUM(CDC) \*\*HODLed Coins \*\*= (1 - Liveliness) \* Supply **HODLer Net Position Change** = Daily or monthly change in HODLed Coins *** # Net Unrealized Profit / Loss (NUPL) Source: https://docs.amberdata.io/data-dictionary/analytics/net-unrealized-profit-loss-nupl *** # Description **Net Unrealized Profit/Loss (NUPL)** is calculated as the difference between an asset’s Market Capitalization and its Realized Capitalization. Realized Cap refers to the aggregate value of all coins based on the price at which they last moved. NUPL, therefore, represents the theoretical net profit or loss that would be realized if all coins in circulation were sold at the current market price. This metric also includes the unrealizable profits or losses associated with lost or inactive coins, which cannot be sold but still impact the calculation. Adamant Capital, the originators of the metric, note that while NUPL reflects the total dollar value of paper gains and losses in a network like Bitcoin, it does not account for relative scale. To address this, **Relative Unrealized Profit/Loss** is usedβ€”NUPL divided by Market Capβ€”to normalize sentiment signals over time and across market cycles. Amberdata provides NUPL data for both Ethereum (ETH) and Bitcoin (BTC). *** # Use Case \*\*Traders: \*\*NUPL can serve as a measure of opportunity cost risk. As NUPL increases, the unrealized gains held by participants also rise, potentially indicating elevated incentive to sell and capture profits. This can provide signals around market turning points or investor behavior under stress. \*\*Analyst: \*\*Analysts can use NUPL to evaluate market-wide positioning and sentiment, helping to assess whether a network is in a profit-taking or accumulation phase. The metric may also support forecasting potential inflection points based on historical profit/loss behavior. \*\*Researcher: \*\*NUPL supports research into the relationship between price action and investor psychology. It can help quantify correlations between sentiment, profit-taking behavior, and price trends. For instance, researchers may study how long a new all-time high in NUPL persists before reversing, potentially offering insight into broader market cycles. *** # Methodology **Relative Unrealized P/L** = (Realized Cap - Market Cap) / Market Cap. *** # New Address Momentum Source: https://docs.amberdata.io/data-dictionary/analytics/new-address-momentum *** # Description The New Address Momentum provides insights into the activity and growth of addresses within the cryptocurrency ecosystem. It encompasses various metrics, including the total number of unique addresses, new addresses (both inputs and outputs), passive addresses with inputs, active addresses with outputs, and the moving averages of new addresses over 30 and 365 days. Active addresses represent those involved in transactions, while passive addresses remain inactive. Notably, the inclusion of centralized exchanges (CEXs) accounts for significant address consolidation. This metric covers ETH and BTC and is crucial for understanding address dynamics and overall network activity. *** # Use Case **Traders** use these metrics to determine if active addresses increase (buy signal) or decrease (sell signal). **Analysts** use these metrics to develop risk metrics on a network. \*\*Researchers \*\*use these metrics to find the correlation between new addresses or addresses with transactions and other data, such as ordinal transactions or ETF interest. *** # Methodology New addresses (inputs and outputs): 1. 30 Day MA: 30-day moving average (DMA) on new addresses (first input or output) 2. 365 Day MA: 365-day moving average (DMA) on new addresses (first input or output) Passive Addresses / Inputs: 1. Daily inputs (addresses and transaction date) 2. Passive Addresses: Number of addresses with an input per day 3. New Inputs: Count distinct of every input address per day on the first instance of an address as an input Active Addresses / Outputs: 1. Daily outputs (addresses and transaction date) 2. Active Addresses: Number of addresses with an output per day 3. New Outputs: Count distinct of every output address per day on the first instance of an address as an output *** *** # Pi Cycle Source: https://docs.amberdata.io/data-dictionary/analytics/pi-cycle *** # Description The Pi Cycle Top is used as an indicator for market β€œoverheating”, and has been attributed to β€œpredicting” 4 different cycle tops. This indicator is used as a sell signal when the price peaks before pulling back. When the 111-day moving average (DMA) crosses or touches the 2x 350 DMA, it is an indicator for the top of the price cycle. Coverage includes BTC and ETH. *** # Use Case **Traders** use pi cycle as a signal for the price top of the current cycle. **Analysts** use this as an indicator for the current cycle state. **Researchers** correlate this metric with other metrics to identify patterns of adoption, *** # Methodology The Pi Cycle Top Indicator is composed of the 111-day moving average and 2x 350-day moving average. *** *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/puell-multiple *** # Description The Puell Multiple is a market indicator that measures Bitcoin miner profitability relative to historical norms. It reflects price movements and is used to identify phases within the broader Bitcoin market cycle. When the Puell Multiple is low, it means the daily USD value of newly minted BTC is below its yearly averageβ€”often signaling potential market bottoms. Conversely, high values suggest that newly minted BTC is worth more than the annual average, which may indicate overheated conditions and potential market tops. This metric implicitly assumes that miner operational costs are relatively stable. As the price of Bitcoin rises, so does the value of mined BTC, improving miner profitability. *** # Use Cases \*\*Traders \*\*use the Puell Multiple as a signal for when miner revenue is higher than historical norms and when the price is likely to drop (being too high) or bounce (being too low). **Analysts** use the Puell Multiple to forecast trends in Bitcoin prices. \*\*Researchers \*\*use the Puell Multiple to help determine the current trading cycle. *** # Methodology **Puell Multiple** = *Daily Issuance Value (USD)* Γ· *365-Day Moving Average of Daily Issuance Value (USD)* * **Daily Issuance Value**: The total USD market value of BTC newly mined each day. * **365-Day Moving Average**: The rolling one-year average of the daily issuance value. This ratio normalizes daily miner revenue against a long-term average, allowing for cycle-based analysis. *** # Frequently Asked Questions **What Puell Multiple value typically indicates miner profit or loss?** * A Puell Multiple of 1.0 or higher generally indicates that miners are operating at a profit. Values below 1.0 suggest that miners may be under financial pressure. **How often is the Puell Multiple updated?** * The metric is updated daily. *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/realized-price *** # Description **Realized Capitalization (Realized Cap)** measures the value of each unit of a cryptocurrency based on the price at which it last moved on-chain. In contrast to **Market Capitalization**, which values all units at the current market price, Realized Cap reflects the collective cost basis of market participants. **Realized Price** is calculated as: **Realized Price = Realized Cap / Supply** This represents the average price paid for all circulating coins, based on the last time each coin moved on-chain. * When **Realized Cap > Market Cap**, the network is in an aggregate unrealized loss. * When **Realized Cap \< Market Cap**, the network is in aggregate profit. * When **Market Price > Realized Price**, market participants are generally in profit. * When **Market Price \< Realized Price**, participants are generally in loss. Coverage includes **Bitcoin (BTC)** and **Ethereum (ETH)**. *** # Use Case \*\*Traders: \*\*Realized Cap can help determine whether activity is primarily off-chain (e.g., on centralized exchanges) or on-chain (e.g., DEX transactions or wallet transfers). \*\*Analysts: \*\*Realized Cap and Realized Price provide insight into whether the market is in a phase of accumulation, profit-taking, or loss realization. \*\*Researchers: \*\*Realized Cap enables comparisons between the crypto market cycle and traditional assets by aligning network valuation trends with macroeconomic indicators or commodity cycles. *** # Methodology Realized Price = Realized Cap / Supply *** # Reserve Risk Source: https://docs.amberdata.io/data-dictionary/analytics/reserve-risk *** # Description **Reserve Risk** is an indicator that measures the confidence of long-term holders relative to the current price of Bitcoin. It reflects the balance between price and conviction. A low Reserve Risk value suggests high confidence among long-term holders while the asset is undervalued. Conversely, a high Reserve Risk value suggests low confidence during periods of elevated price, indicating increased speculative risk. Reserve Risk is designed to identify optimal periods for capital deployment based on long-term holder sentiment. Historically, periods of low Reserve Risk have been associated with outsized long-term returns, while periods of high Reserve Risk have preceded market corrections or sustained downtrends. Coverage is currently available for **Bitcoin (BTC)** only. *** # Use Case Reserve risk can help traders understand when it is a good time to buy and researchers to analyze the confidence of long-term holders. *** # Methodology Reserve Risk = Price / HODL Bank HODL Bank = cumulative sum(price - median value of Coin Days Destroyed) *** *** # Sample Data Source: https://docs.amberdata.io/data-dictionary/analytics/sample-data Below are some sample datasets from the institutional metrics in CSV format. | Metric Name | Sample Files | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ***Institutional Bitcoin Market Indicators*** | | | Bitcoin Price and Moving Averages | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_price_moving_average+-+amberLens+Sample.csv) | | Market Cap vs Realized Cap | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_marketcap_v_realized_price+-+amberLens+Sample.csv) | | Bitcoin Yardstick | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_yardstick+-+amberLens+Sample.csv) | | MVRV | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_mvrv+-+amberLens+Sample.csv) | | Reserve Risk | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_reverse_risk+-+amberLens+Sample.csv) | | Pi Cycle | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_pi_cycle+-+amberLens+Sample.csv) | | Stock to Flow | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_stock_to_flow+-+Sheet1.csv) | | Realized Price | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_realized_price+-+amberLens+Sample.csv) | | NUPL | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_nupl+-+amberLens+Sample.csv) | | Bitcoin HODLed or Lost | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_hodled_or_lost+-+amberLens+Sample.csv) | | Monthly HODL Net Position Change | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_monthly_hodl_net_position_change+-+amberLens+Sample.csv) | | Liquid vs Illiquid Supply | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_liquid_v_illiquid+-+amberLens+Sample.csv) | | Percent of Supply in Profit | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_percent_supply_in_profit+-+amberLens+Sample.csv) | | BTC HODL Waves | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_hodl_waves+-+amberLens+Sample.csv) | | BTC Balance Buckets: Number of Addresses, BTC Balance Buckets: Supply Held | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_balance_bucket_num_addresses+-+amberLens+Sample.csv) | | USD Balance Buckets: Number of Addresses | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_usd_balance_bucket_num_address+-+amberLens+Sample.csv) | | Daily Address Activity, New Address Momentum, Daily New Addresses | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_daily_address_activity+-+amberLens+Sample.csv) | | Puell Multiple | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_puell_multiple+-+amberLens+Sample.csv) | | Miner Supply Spent | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_miner_supply_spent+-+amberLens+Sample.csv) | | Miner Position Index | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+Institutional+Metrics/sample_btc_miner_position_index+-+amberLens+Sample.csv) | | ***Institutional Ethereum Market Indicators*** | | | Ethereum Price and Moving Averages | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_price_moving_average+-+amberLens+Sample.csv) | | Market Cap vs Realized Cap | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_marketcap_v_realized_cap+-+amberLens+Sample.csv) | | MVRV | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_mvrv+-+amberLens+Sample.csv) | | Pi Cycle | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_pi_cycle+-+amberLens+Sample.csv) | | Realized Price | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_realized_price+-+amberLens+Sample.csv) | | Net Unrealized Profit / Loss (NUPL) | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_nupl+-+amberLens+Sample.csv) | | Liquid vs Illiquid Supply | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_liquid_v_illiquid_supply+-+amberLens+Sample.csv) | | ETH Balance Buckets: Number of Addresses | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_balance_buckets+-+amberLens+Sample.csv) | | ETH Balance Buckets: Supply Held | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_balance_buckets+-+amberLens+Sample.csv) | | USD Balance Buckets: Number of Addresses | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_usd_balance_buckets+-+amberLens+Sample.csv) | | Daily Address Activity, New Address Momentum, Daily New Addresses | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Institutional+Metrics/sample_eth_daily_active_addresses+-+amberLens+Sample.csv) | | ***Ethereum Network Metrics*** | | | ETH Network Metrics | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+Network+Metrics/sample_eth_supply+-+Sheet1.csv) | | ***Ethereum Treasury Backed RWA's*** | | | Ethereum RWA Marketcap | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+RWA/sample_eth_rwa_marketcap+amberLens+sample.csv) | | ETH Treasury Backed RWA: Unique Holders | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+RWA/sample_eth_rwa_unique_holders+-+amberLens+Sample.csv) | | Ethereum RWA Treasury Overview | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+RWA/sample_eth_rwa_overview+-+amberLens+Sample.csv) | | ***BTC ETF*** | | | BTC ETF Holdings | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+ETF/sample_btc_etf_holdings+-+amberLens+Sample.csv) | | BTC ETF Flow (\$) | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+ETF/sample_btc_etf_flow_usd+-+amberLens+Sample.csv) | | BTC ETF Flows (β‚Ώ) | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+ETF/sample_btc_etf_flow_btc+-+amberLens+Sample.csv) | | BTC ETF Net Flows | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/BTC+ETF/sample_btc_etf_net_flows_usd+-+amberLens+Sample.csv) | | ***ETH ETF*** | | | ETH ETF Holdings | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+ETF/sample_eth_etf_holdings-amberLens+Sample.csv) | | ETH ETF Flows - All | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/ETH+ETF/sample_eth_etf_flows_eth-amberLens+Sample.csv) | | ***Ethereum Staking and Restaking*** | | | Liquid Staking - 7 Day APY | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_7_day_apy+-+amberLens+Sample.csv) | | Liquid Staking - 30 Day APY | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_30_day_apy+-+amberLens+Sample.csv) | | Liquid Staking All Deposits and Withdraws | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_all_deposits_withdraws+-+amberLens+Sample.csv) | | Liquid Staking Daily Balance Change | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_daily_balance_change+-+amberLens+Sample.csv) | | Liquid Staking Eigen Layer TVL By Asset | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_eigen_layer_tvl_by_asset+-+amberLens+Sample.csv) | | Liquid Staking ETH APY | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_eth_apy+-+AmberLens+Sample.csv) | | Liquid Staking Token Onchain Supply | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_onchain_supply+-+amberLens+Sample.csv) | | Liquid Staking Operator Delegation | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_operator_delegation+-+amberLens+Sample.csv) | | Liquid Staking Pods Deployed | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_pods_deployed+-+amberLens+Sample.csv) | | Liquid Staking Registered AVS | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/Liquid+\(Re-\)Staking+Metrics/liquid_staking_registered_avs+-+amberLens+Sample.csv) | | ***DeFi Lending*** | | | Daily Protocol Metrics | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/DeFi+Lending/amberLens+DeFi+dashboard+-+Samples+-+Protocols+Sample+For+S3.csv) | | Daily Asset Metrics | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/DeFi+Lending/amberLens+DeFi+dashboard+-+Samples+-+Assets+Sample+For+S3.csv) | | Stablecoins Daily | [Download](https://amberdata-samples.s3.amazonaws.com/amberlens/DeFi+Lending/amberLens+DeFi+dashboard+-+Samples+-+Stablecoin+Sample+For+S3.csv) | # Bid Ask Spread Source: https://docs.amberdata.io/data-dictionary/analytics/spot/bid-ask # Description Bid-Ask Spread measures the difference between the best bid and best ask prices for a trading pair. It returns both: * The absolute spread (in quote currency) * The spread as a percentage of the mid-price This dual representation allows for cross-pair and cross-exchange comparison of liquidity conditions. *** # Details This metric provides a view of market tightness and liquidity fragmentation. By analyzing how wide or narrow the spread is, traders can quickly identify: * The most liquid exchange for a given asset * Which trading pairs or quote currencies offer the best execution conditions The percentage spread is especially useful when comparing instruments with different quote currencies (e.g., BTC-USDT vs. BTC-USD vs. BTC-EUR), as it normalizes price scale effects. *** # API Endpoints [/spot-analytics-information-order-book-depth](/http/analytics/spot/information-depth-analytics-pairs-and-exchanges) [/spot-analytics-order-book-depth-bid-ask-spread](/http/analytics/spot/bid-ask-spread) *** # Availability We cover major tokens such as BTC, ETH, XRP, SOL, and USDT for exchanges with limited Depth order count, while all pairs for exchanges with Full Depth. Please use the information endpoint to find all coverage and exact trading pairs. Note: \*major pairs only | Exchange | History | Granularity | Depth Order Count | | --------------- | ---------- | ----------- | ----------------- | | Binance | 2024-01-01 | 1min | 5000 | | Binance.us | 2025-01-01 | 1min | 5000 | | Bitstamp | 2025-01-01 | 1min | Full | | Bullish | 2025-03-16 | 1min | 150 | | Deribit | 2025-03-19 | 1min | Full | | GDAX (Coinbase) | 2024-01-01 | 1min | Full | | Gemini | 2024-06-01 | 1min | Full | | Huobi\* | 2024-01-01 | 1min | 150 | | itBit | 2025-03-05 | 1min | Full | | Kraken\* | 2025-01-01 | 1min | 500 | | OKEx (OKX) | 2024-01-01 | 1min | 1000 | | bybit\* | 2024-01-01 | 1min | 200 | *** # Frequently Asked Questions **How is the absolute spread calculated?** * `spread = bestAskPrice βˆ’ bestBidPrice` * This is returned in the quote currency of the pair. **What does spreadPercent represent?** * It’s the absolute spread divided by the mid-price: * `spreadPercent = (spread / midPrice) Γ— 100` * This normalizes spread data across different pairs. **How can I compare liquidity across exchanges?** * Leave the exchange parameter blank to return spread data across all supported exchanges for the same pair. You can then quickly identify the exchange with the tightest spread. **What does fuzzyMatch do?** * If `fuzzyMatch = true`, the endpoint returns all trading pairs related to an underlying asset. For example, searching for btc\_usd with fuzzy matching would return BTC-USDT, BTC-ETH, BTC-EUR, etc. *** # LWAP (Liquidity-Weighted Average Price) Source: https://docs.amberdata.io/data-dictionary/analytics/spot/lwap # Description LWAP is a liquidity-weighted average of prices derived from the order book. Unlike VWAP, which is based on executed volume, LWAP focuses on the price levels with the most available liquidity. *** # Details LWAP offers a view of the true market-clearing price based on where liquidity sits, rather than where trades occur. It's particularly helpful for estimating where large trades would most likely be filled without disrupting the market. Often used to compare with VWAP or to assess liquidity health at a given point in time. # API Endpoints [/spot-analytics-information-order-book-depth](/http/analytics/spot/information-depth-analytics-pairs-and-exchanges) [/spot-analytics-order-book-depth-lwap](/http/analytics/spot/lwap) *** # Availability We cover major tokens such as BTC, ETH, XRP, SOL, and USDT for exchanges with limited Depth order count, while all pairs for exchanges with Full Depth. Please use the information endpoint to find all coverage and exact trading pairs. Note: \*major pairs only | Exchange | History | Granularity | Depth Order Count | | --------------- | ---------- | ----------- | ----------------- | | Binance | 2024-01-01 | 1min | 5000 | | Binance.us | 2025-01-01 | 1min | 5000 | | Bitstamp | 2025-01-01 | 1min | Full | | Bullish | 2025-03-16 | 1min | 150 | | Deribit | 2025-03-19 | 1min | Full | | GDAX (Coinbase) | 2024-01-01 | 1min | Full | | Gemini | 2024-06-01 | 1min | Full | | Huobi\* | 2024-01-01 | 1min | 150 | | itBit | 2025-03-05 | 1min | Full | | Kraken\* | 2025-01-01 | 1min | 500 | | OKEx (OKX) | 2024-01-01 | 1min | 1000 | | bybit\* | 2024-01-01 | 1min | 200 | *** # Frequently Asked Questions **How is LWAP different from VWAP?** * VWAP is trade-executed price weighted by volume; LWAP uses order book liquidity as the weighting input. LWAP is a forward-looking execution model, whereas VWAP is historical. **Why is LWAP important?** * It can help traders and quants simulate trade impact or optimize execution paths. *** # Order Book Dashboard Source: https://docs.amberdata.io/data-dictionary/analytics/spot/order-book-dashboard # Definition Order Book Dashboard provides an average view of depth liquidity across exchanges and pairs over a chosen time window. It allows for easy comparison of liquidity environments. *** # Details This endpoint aggregates average depth values at specified basis point levels (e.g., 10bps, 50bps) over time, showing how market depth evolves and how certain exchanges or pairs compare in terms of liquidity provision. Used for both historical analysis and monitoring liquidity fragmentation across the market *** # API Endpoints [/spot-analytics-information-order-book-depth](/http/analytics/spot/information-depth-analytics-pairs-and-exchanges) [/spot-analytics-order-book-depth-dashboard](/http/analytics/spot/depth-dashboard) *** # Availability We cover major tokens such as BTC, ETH, XRP, SOL, and USDT for exchanges with limited Depth order count, while all pairs for exchanges with Full Depth. Please use the information endpoint to find all coverage and exact trading pairs. Note: \*major pairs only | Exchange | History | Granularity | Depth Order Count | | --------------- | ---------- | ----------- | ----------------- | | Binance | 2024-01-01 | 1min | 5000 | | Binance.us | 2025-01-01 | 1min | 5000 | | Bitstamp | 2025-01-01 | 1min | Full | | Bullish | 2025-03-16 | 1min | 150 | | Deribit | 2025-03-19 | 1min | Full | | GDAX (Coinbase) | 2024-01-01 | 1min | Full | | Gemini | 2024-06-01 | 1min | Full | | Huobi\* | 2024-01-01 | 1min | 150 | | itBit | 2025-03-05 | 1min | Full | | Kraken\* | 2025-01-01 | 1min | 500 | | OKEx (OKX) | 2024-01-01 | 1min | 1000 | | bybit\* | 2024-01-01 | 1min | 200 | *** # Frequently Asked Questions **How does this differ from the order book depth endpoint?** * This dashboard aggregates and averages depth metrics, rather than providing point-in-time depth snapshots. It's useful for high-level analysis across markets. **Can I use this to compare exchanges?** * Yes β€” average depth at various bps levels is included by exchange and trading pair. *** # Order Book Depth Source: https://docs.amberdata.io/data-dictionary/analytics/spot/order-book-depth # Description Order Book Depth shows how much liquidity is available at varying distances from the best-bid/best-ask price, measured in basis points (bps). This provides a snapshot of market robustness and order book structure. *** # Details This metric analyzes both bid and ask side liquidity within percentage ranges from the best-bid/best-ask price. By aggregating depth across tranches like 10bps, 50bps, or 100bps, it becomes easier to identify where meaningful liquidity resides. Liquidity concentration (e.g., most bids sitting within 20bps) can help assess potential slippage and execution quality, especially during large trades or volatility spikes. [/spot-analytics-information-order-book-depth](/http/analytics/spot/information-depth-analytics-pairs-and-exchanges) [/spot-analytics-order-book-depth](/http/analytics/spot/depth) [/spot-analytics-order-book-depth-average](/http/analytics/spot/average-depth) *** # Availability We cover major tokens such as BTC, ETH, XRP, SOL, and USDT for exchanges with limited Depth order count, while all pairs for exchanges with Full Depth. Please use the information endpoint to find all coverage and exact trading pairs. Note: \*major pairs only | Exchange | History | Granularity | Depth Order Count | | --------------- | ---------- | ----------- | ----------------- | | Binance | 2024-01-01 | 1min | 5000 | | Binance.us | 2025-01-01 | 1min | 5000 | | Bitstamp | 2025-01-01 | 1min | Full | | Bullish | 2025-03-16 | 1min | 150 | | Deribit | 2025-03-19 | 1min | Full | | GDAX (Coinbase) | 2024-01-01 | 1min | Full | | Gemini | 2024-06-01 | 1min | Full | | Huobi\* | 2024-01-01 | 1min | 150 | | itBit | 2025-03-05 | 1min | Full | | Kraken\* | 2025-01-01 | 1min | 500 | | OKEx (OKX) | 2024-01-01 | 1min | 1000 | | bybit\* | 2024-01-01 | 1min | 200 | *** # Frequently Asked Questions **What are basis points in this context?** * One basis point is 0.01%. So 100bps means 1% away from the best-bid/best-ask price. The endpoint tracks liquidity depth at various bps levels. **Why is this useful during volatile periods?** * Order book depth gives a more complete view of where liquidity sits, allowing traders to anticipate price impact or dislocation. *** # Order Book Pressure Source: https://docs.amberdata.io/data-dictionary/analytics/spot/order-book-pressure # Definition Order Book Pressure is a market sentiment metric that quantifies the imbalance between buy-side and sell-side liquidity. It’s calculated as: \`Order Book Pressure = Bid Volume βˆ’ Ask Volume\`\` A positive value suggests stronger demand (buying pressure), while a negative value implies stronger supply (selling pressure). *** # Details Order Book Pressure helps traders and analysts gauge the aggressiveness of bids versus offers (asks) in real time. This metric is especially useful during volatile market events, offering insight into short-term sentiment and potential directional bias. The calculation uses visible volume in the order book at a given moment, not executed trades. It reflects intent to trade, which can be a leading indicator of market moves. *** # API Endpoints [/spot-analytics-information-order-book-depth](/http/analytics/spot/information-depth-analytics-pairs-and-exchanges) [/spot-analytics/order-book-pressure](/http/analytics/spot/pressure) *** # Availability We cover major tokens such as BTC, ETH, XRP, SOL, and USDT for exchanges with limited Depth order count, while all pairs for exchanges with Full Depth. Please use the information endpoint to find all coverage and exact trading pairs. Note: \*major pairs only | Exchange | History | Granularity | Depth Order Count | | --------------- | ---------- | ----------- | ----------------- | | Binance | 2024-01-01 | 1min | 5000 | | Binance.us | 2025-01-01 | 1min | 5000 | | Bitstamp | 2025-01-01 | 1min | Full | | Bullish | 2025-03-16 | 1min | 150 | | Deribit | 2025-03-19 | 1min | Full | | GDAX (Coinbase) | 2024-01-01 | 1min | Full | | Gemini | 2024-06-01 | 1min | Full | | Huobi\* | 2024-01-01 | 1min | 150 | | itBit | 2025-03-05 | 1min | Full | | Kraken\* | 2025-01-01 | 1min | 500 | | OKEx (OKX) | 2024-01-01 | 1min | 1000 | | bybit\* | 2024-01-01 | 1min | 200 | *** # Frequently Asked Questions **What’s the difference between Order Book Pressure and Trade Pressure?** * Order Book Pressure reflects intent to trade based on resting orders, while Trade Pressure reflects executed volume. Both are useful but offer different perspectives. **How often is this data updated?** * Data is sampled at regular intervals (e.g., 1-minute), depending on the query. **Can I use this to predict price movements?** * While not predictive on its own, persistent pressure in one direction often precedes price continuation or reversal, especially when confirmed by other indicators. *** # Trade Frequency Source: https://docs.amberdata.io/data-dictionary/analytics/spot/trade-frequency # Description Trade Frequency measures the number of trades executed over a given time interval. It reveals market activity intensity and the presence of algorithmic trading. *** # Details Trade frequency spikes β€” especially during high volatility β€” often indicate a surge in automated activity (e.g., bots). Monitoring this helps assess market responsiveness and behavioral shifts. High-frequency bursts with low trade size typically point to retail or algorithmic trading activity. *** # API Endpoints [/spot-analytics-information-trade-analytics-pairs](/http/analytics/spot/information-trade-analytics-pairs) [/spot-analytics-information-trade-exchange-support-per-pair](/http/analytics/spot/information-trade-exchange-support-per-pair) [/spot-analytics-trade-frequency](/http/analytics/spot/trade-frequency) *** # Availability Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | ------------------------------ | | Binance | 2023-06-01 | 1-min, before 2025 then 1-hour | | Binance.us | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bitstamp | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bybit | 2023-06-01 | 1-min, before 2025 then 1-hour | | GDAX (Coinbase) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gemini | 2023-06-01 | 1-min, before 2025 then 1-hour | | OKEx (OKX) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Poloniex | 2023-06-01 | 1-min, before 2025 then 1-hour | | itBit | 2024-03-05 | 1-min, before 2025 then 1-hour | | Mercado Bitcoin | 2024-03-25 | 1-min, before 2025 then 1-hour | | Bitget | 2024-10-01 | 1-min, before 2025 then 1-hour | | Huobi | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2023-06-01 | 1-min, before 2025 then 1-hour | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | | LMAX | 2025-01-01 | 1min | | Kraken | 2023-06-01 | 1-min, before 2025 then 1-hour | *** # Frequently Asked Questions **What is the value of tracking trade frequency?** * It’s a signal of trading intensity and can hint at algo or bot-driven market activity. **Does it measure trade size too?** * This endpoint focuses on count. Use in combination with volume data for full context. *** # Trade Pressure Source: https://docs.amberdata.io/data-dictionary/analytics/spot/trade-pressure # Description Spot Trade Pressure measures the net buying vs. selling activity, calculated as: `Trade Pressure = Buy Volume βˆ’ Sell Volume` It can be further segmented by trade size to analyze behavior across retail and institutional flows. *** # Details Trade pressure offers directional insight from executed trades β€” not just order book intent. When broken down by trade size, it allows for segmentation: small trades (retail), medium (active traders), and large (institutional). Trade pressure is useful for real-time flow analysis and narrative confirmation. *** # API Endpoints [/spot-analytics-information-trade-analytics-pairs](/http/analytics/spot/information-trade-analytics-pairs) [/spot-analytics-information-trade-exchange-support-per-pair](/http/analytics/spot/information-trade-exchange-support-per-pair) [/spot-analytics-trade-pressure](/http/analytics/spot/trade-pressure) *** # Availability Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | ------------------------------ | | Binance | 2023-06-01 | 1-min, before 2025 then 1-hour | | Binance.us | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bitstamp | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bybit | 2023-06-01 | 1-min, before 2025 then 1-hour | | GDAX (Coinbase) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gemini | 2023-06-01 | 1-min, before 2025 then 1-hour | | OKEx (OKX) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Poloniex | 2023-06-01 | 1-min, before 2025 then 1-hour | | itBit | 2024-03-05 | 1-min, before 2025 then 1-hour | | Mercado Bitcoin | 2024-03-25 | 1-min, before 2025 then 1-hour | | Bitget | 2024-10-01 | 1-min, before 2025 then 1-hour | | Huobi | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2023-06-01 | 1-min, before 2025 then 1-hour | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | | LMAX | 2025-01-01 | 1min | | Kraken | 2023-06-01 | 1-min, before 2025 then 1-hour | *** # Frequently Asked Questions **How is this different from Order Book Pressure?** * Order Book Pressure is based on resting orders; Trade Pressure is based on executed trades. Both reflect sentiment but at different stages of market intent. **Can this distinguish between trader types?** * Yes β€” by analyzing trade size bands, you can infer participation from bots, retail, or institutions. *** # Asset Volumes USD Source: https://docs.amberdata.io/data-dictionary/analytics/spot/volumes-asset # Description This endpoint displays the total volume per base asset or specifc pair, normalized to USD. This means that crypto-to-crypto pairs (such as ETH\_BTC) are converted to USD before aggregation. Users can pass an optional boolean parameter to include pairs where the asset is on the quote side, example xyz\_btc where btc is target asset. *** # Details Asset volumes USD allows users to quickly see aggregated volumes, converted into USD terms, across all pairs an exchange offer for a particular asset. # API Endpoints [/spot-analytics-volumes-asset](/http/analytics/spot/volumes-asset) *** # Availability Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | ------------------------------ | | Binance | 2023-06-01 | 1-min, before 2025 then 1-hour | | Binance.us | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bitstamp | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bybit | 2023-06-01 | 1-min, before 2025 then 1-hour | | GDAX (Coinbase) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gemini | 2023-06-01 | 1-min, before 2025 then 1-hour | | OKEx (OKX) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Poloniex | 2023-06-01 | 1-min, before 2025 then 1-hour | | itBit | 2024-03-05 | 1-min, before 2025 then 1-hour | | Mercado Bitcoin | 2024-03-25 | 1-min, before 2025 then 1-hour | | Bitget | 2024-10-01 | 1-min, before 2025 then 1-hour | | Huobi | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2023-06-01 | 1-min, before 2025 then 1-hour | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | | LMAX | 2025-01-01 | 1min | | Kraken | 2023-06-01 | 1-min, before 2025 then 1-hour | *** # Exchange Volumes USD Source: https://docs.amberdata.io/data-dictionary/analytics/spot/volumes-exchange # Description This endpoint displays the total volume per exchange for all available pairs, normalized to USD. This means that crypto-to-crypto pairs (such as ETH\_BTC) are converted to USD before aggregation. Users can pass an exchange parameter to isolate volume data for a specific exchange or leave it blank to retrieve data for all supported exchanges. Users can also isolate volume that meet a size threshold using the β€œorderSizeCategoryUsd” parameter. A useful example might be to pass 100k+ threshold to measure which exchanges have the most β€œlarge ticket” volume (aka β€œwhale” volume). *** # Details Exchange volumes USD allows users to quickly see aggregated volumes, converted into USD terms, across all pairs an exchange offer. This helps users identify venues with liquidity and the associated time of day. # API Endpoints [/spot-analytics-volumes-exchange](/http/analytics/spot/volumes-exchange) *** # Availability Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | ------------------------------ | | Binance | 2023-06-01 | 1-min, before 2025 then 1-hour | | Binance.us | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bitstamp | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bybit | 2023-06-01 | 1-min, before 2025 then 1-hour | | GDAX (Coinbase) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gemini | 2023-06-01 | 1-min, before 2025 then 1-hour | | OKEx (OKX) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Poloniex | 2023-06-01 | 1-min, before 2025 then 1-hour | | itBit | 2024-03-05 | 1-min, before 2025 then 1-hour | | Mercado Bitcoin | 2024-03-25 | 1-min, before 2025 then 1-hour | | Bitget | 2024-10-01 | 1-min, before 2025 then 1-hour | | Huobi | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2023-06-01 | 1-min, before 2025 then 1-hour | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | | LMAX | 2025-01-01 | 1min | | Kraken | 2023-06-01 | 1-min, before 2025 then 1-hour | *** # VWAP - TWAP Source: https://docs.amberdata.io/data-dictionary/analytics/spot/vwap-twap # Description The VWAP (Volume Weighted Average Price) for BTC/USDT and other pairs on a crypto exchanges like Binance, is calculated every minute using trade data. *** # Details VWAP is computed by taking the sum of the product of each trade’s price and size (i.e., trade price Γ— trade volume) within the 1-minute interval, and dividing that by the total traded volume in that same interval. This provides a time-specific average price that accounts for trade size, offering a more accurate reflection of market activity than a simple average. The TWAP users the time-weighted average of the β€œclose” price for each 1-minute candle. We use the close price because it’s the last traded price for that minute, which provides as consistent price that matches the minute’s end as closely as possible. # API Endpoints [/spot-analytics-information-trade-analytics-pairs](/http/analytics/spot/information-trade-analytics-pairs) [/spot-analytics-information-trade-exchange-support-per-pair](/http/analytics/spot/information-trade-exchange-support-per-pair) [/spot-analytics-vwap-twap](/http/analytics/spot/vwap-twap) *** # Availability Please use the information endpoint to find all coverage and exact trading pairs. | Exchange | History | Granularity | | --------------- | ---------- | ------------------------------ | | Binance | 2023-06-01 | 1-min, before 2025 then 1-hour | | Binance.us | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bitstamp | 2023-06-01 | 1-min, before 2025 then 1-hour | | Bybit | 2023-06-01 | 1-min, before 2025 then 1-hour | | GDAX (Coinbase) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gemini | 2023-06-01 | 1-min, before 2025 then 1-hour | | OKEx (OKX) | 2023-06-01 | 1-min, before 2025 then 1-hour | | Poloniex | 2023-06-01 | 1-min, before 2025 then 1-hour | | itBit | 2024-03-05 | 1-min, before 2025 then 1-hour | | Mercado Bitcoin | 2024-03-25 | 1-min, before 2025 then 1-hour | | Bitget | 2024-10-01 | 1-min, before 2025 then 1-hour | | Huobi | 2023-06-01 | 1-min, before 2025 then 1-hour | | Gate.io | 2025-01-07 | 1min | | Crypto.com | 2025-02-19 | 1min | | KuCoin | 2023-06-01 | 1-min, before 2025 then 1-hour | | HashKey | 2025-02-28 | 1min | | Bullish | 2025-03-19 | 1min | | Deribit | 2025-03-20 | 1min | | Coinbase Intl | 2025-04-01 | 1min | | Upbit | 2025-04-28 | 1min | | CoinW | 2025-05-15 | 1min | | LMAX | 2025-01-01 | 1min | | Kraken | 2023-06-01 | 1-min, before 2025 then 1-hour | *** # Stock-to-Flow Source: https://docs.amberdata.io/data-dictionary/analytics/stock-to-flow *** # Description The **Stock-to-Flow (S2F)** model measures the scarcity of an asset by comparing its existing circulating supply (**stock**) to its annual production rate (**flow**). This metric is commonly applied to commodities such as gold and silver, and has been adapted to analyze Bitcoin. In the case of Bitcoin, the model reflects programmed scarcityβ€”specifically, the scheduled halving events that reduce new issuance over time. As a result, Bitcoin’s stock-to-flow ratio increases predictably, reinforcing its narrative as a scarce digital asset. *** # Use Cases **Price forecasting**: Investors and analysts use the model to predict future price movements of Bitcoin based on its scarcity dynamics. **Investment strategy**: Traders and investors may incorporate the Stock-to-Flow model into their investment strategies to assess the long-term value proposition of Bitcoin and make informed decisions about buying, holding, or selling. **Market analysis**: The Stock-to-Flow model provides insights into the fundamental factors driving Bitcoin's price and can be used alongside other analytical tools to analyze market trends and behavior. **Risk management**: Understanding Bitcoin's scarcity properties through the Stock-to-Flow model can help investors manage risk by assessing the potential impact of supply-side dynamics on price volatility. *** # Overview Source: https://docs.amberdata.io/data-dictionary/analytics/supply-eth Note: This dataset is updated daily and is available via REST API, Databricks, and Snowflake. *** # Description This metric tracks the current amount of ETH in circulation and reflects changes resulting from Ethereum's shift from Proof-of-Work (PoW) to Proof-of-Stake (PoS) following **The Merge** in September 2022. Post-Merge, Ethereum introduced fee burning (via EIP-1559) and reduced issuance, making ETH a potentially deflationary asset. * **Monetary Policy & Inflation**: Tracking ETH supply growth allows users to evaluate Ethereum’s monetary policy. Post-Merge, issuance dropped significantly and fee burns introduced negative supply pressure, changing ETH’s inflation profile. * **Market Dynamics**: Supply changes can impact ETH price. An increasing supply may dilute value, while deflationary pressure can support price appreciation. Traders watch this closely for macro signals. * **Network Health & Adoption**: Supply trends also reflect activity on the Ethereum network. A growing supply may indicate increased usage, while a declining or flat supply could point to reduced demand or higher fee burning. *** # Use Cases \*\*Traders: \*\*Monitor ETH issuance trends to identify potential supply-demand imbalances and forecast market movements. \*\*Analysts: \*\*Incorporate issuance data into volatility models or liquidity analyses to enhance strategy development and risk forecasting. \*\*Researchers: \*\*Study issuance trends in the context of protocol upgrades, validator dynamics, and broader economic modeling of Ethereum's monetary system. *** # Methodology **Pre-Merge Block Rewards** * **Block 1**: 72,009,990 ETH β€” Initial ICO allocation * **Block 2 to 4,370,000**: 5 ETH/block β€” Original issuance * **Block 4,370,001 to 7,280,000**: 3 ETH/block β€” Byzantium upgrade * **Block 7,280,001 to 15,537,393**: 2 ETH/block β€” Constantinople to The Merge **Post EIP-1559 (London Fork)** * **ETH Burned = GasUsed Γ— BaseFeePerGas** * Fee burning began at block `12965000` with EIP-1559. **Post-Merge ETH Issuance (Proof-of-Stake)** * Ethereum now issues ETH based on validator rewards rather than block mining. * There are approximately **225 epochs per day**: `365.25 X 225 = 82181 Epochs per year, and a BASE_REWARD_FACTOR = 64` **Base Reward Formula**: * `BASE_REWARD_FACTOR = 64` * `N = Number of validators = Current ETH Staked / 32` * Current ETH Staked = Total ETH Deposited βˆ’ ETH Withdrawn (from Beacon chain) *** # Frequently Asked Questions **How often is this chart updated?** * Daily. *** # Price and Moving Averages Source: https://docs.amberdata.io/data-dictionary/analytics/topbottom-indicators *** # Description Price is often the primary starting point for analyzing assets. By utilizing daily and weekly moving averages, the price trends of assets such as BTC and ETH can be effectively tracked alongside key technical indicators like support, resistance, and trendlines. Commonly used moving averages include the 50-day moving average (50DMA) and the 200-day moving average (200DMA). These metrics help identify patterns such as the "death cross," which signals price weakness and has historically preceded price rebounds. During an uptrend, moving averages often act as support levels, indicating the potential bottom of a market cycle. Conversely, in a downtrend, they can function as resistance levels, suggesting the top of a market cycle. Amberdata provides coverage of BTC and ETH prices along with their respective moving averages. *** # Use Case Moving averages serve as short- and mid-term price indicators widely employed in traditional financial markets for trend analysis and trading strategy development. *** # Methodology The moving averages are calculated by averaging the asset's price over the preceding *n* days. *** *** # Real World Assets Source: https://docs.amberdata.io/data-dictionary/analytics/treasury-backed-rwa Note: These datasets are available via REST API, Databricks, and Snowflake. *** # Description The Amberdata Intelligence Real-World Assets dashboard covers various assets tokenized on Ethereum. These dashboards currently cover: * BlackRock: BUIDL * Ondo: OUSG * Matrixdock: STBT * Backed: IB01 * Hashnote: USYC * OpenEden: TBILL * Maple: MPLcashUSDC * Superstate: USTB. *** # Use Case **Traders** For traders, tokenized treasuries present advantages such as enhanced liquidity, faster settlement times, and access to a broader market. These attributes can contribute to increased price volatility and trading opportunities. Additionally, fractional ownership enables traders to implement more diversified and flexible strategies with potentially lower capital outlays. **Researchers** Researchers focus on examining the transformative impact of blockchain-based financial instruments like tokenized treasuries. They explore how blockchain technology improves the efficiency, transparency, and accessibility of government bonds. Researchers are particularly interested in innovations such as programmable features and smart contracts, and how these developments may influence public finance, monetary policy, and investor behavior over the long term. **Analysts** Analysts, especially those in financial institutions or advisory roles, assess tokenized treasuries to provide strategic insights and investment recommendations. Their evaluations emphasize risk management, market trends, and the long-term benefits of incorporating tokenized treasuries into diversified portfolios. Analysts study how tokenization affects market liquidity, regulatory environments, and the integration of digital assets with traditional financial markets. Their goal is to identify how tokenized treasuries can optimize returns, manage risk, and support digital transformation in finance. *** # Methodology **Indexed contract addresses:** `0x7712c34205737192402172409a8f7ccef8aa2aec: BUIDL` `0x43415eb6ff9db7e26a15b704e7a3edce97d31c4e: USTB` `0x1b19c19393e2d034d8ff31ff34c81252fcbbee92: OUSG` `0x136471a34f6ef19fe571effc1ca711fdb8e49f2b: USYC` `0x530824da86689c9c17cdc2871ff29b058345b44a: STBT` `0xca30c93b02514f86d5c86a6e375e3a330b435fb5: ID01` `0xdd50c053c096cb04a3e3362e2b622529ec5f2e8a: TBILL` **Market Capitalization**\ Market capitalization is calculated daily by aggregating the total tokens issued minus tokens redeemed to determine total supply. If an oracle contract is available from the protocol, the latest reported price is used to value the supply. In the absence of an oracle, a default price of \$1 is assumed. **Unique Holders**\ The number of unique holders is derived from token transfer data by counting distinct wallets holding a positive balance each day. **Top Holders**\ Top holders are identified by calculating the current token balances of all wallets using transfer data. *** # USD Balance Bucket Source: https://docs.amberdata.io/data-dictionary/analytics/usd-balance-bucket *** # Description The USD Balance Buckets offer a comprehensive overview of addresses and their token holdings across a range of balances, covering amounts from small fractions up to \$10,000,000 USD. Coverage includes ETH and BTC for balance buckets. *** # Use Case **Traders** Traders use USD Balance Bucket metrics to track network dynamics, including address balance changes, asset liquidity shifts, and profit fluctuations, guiding strategic trading decisions. **Analyst** Analysts leverage these metrics for enhancing portfolio analysis, focusing on profitability and wallet distribution to make informed recommendations. **Researcher** Researchers employ this data to identify market trends and patterns in network behavior, aiding in comprehensive market studies. *** # Methodology USD Balance Buckets categorize address balances into distinct groups, detailing the number of addresses and the total balance within each category. 1. When the balance, after being multiplied by the current BTC or ETH price, equals 0, it is classified as '0 USD'. 2. For balances resulting in less than \$100 after conversion, they fall under the '100 USD' category. 3. Balances yielding less than \$1,000 but exceeding the previous category are labeled as '1,000 USD'. 4. This progression continues upwards, with each category accommodating increasingly larger amounts: '10,000 USD', '100,000 USD', '1,000,000 USD', and '10,000,000 USD'. 5. Any balance equal to or exceeding \$10,000,000 is grouped into the '10,000,000+ USD' category. *** *** # Downloads Source: https://docs.amberdata.io/data-dictionary/api-specs Below you can download the OpenAPI specification files for each of our APIs. These specs provide the full contract for our endpoints and can be imported directly into tools like Postman, Insomnia, or your favorite client library. * [Derivatives](/http/analytics/derivatives/openapi.yaml) * [Spot](/http/analytics/spot/openapi.yaml) * [Arc](/http/arc/openapi.yaml) * [Blockchain](/http/blockchain/openapi.yaml) * [DeFi](/http/defi/openapi.yaml) * [DeFi Market](/http/defi-market/openapi.yaml) * [Market](/http/market/openapi.yaml) * [Metrics](/http/metrics/openapi.yaml) * [Price](/http/price/openapi.yaml) # Asset Reference and Classification Source: https://docs.amberdata.io/data-dictionary/arc-overview # Description Asset Reference and Classification (ARC) is an institutional-grade security master database for digital assets that aims to provide a transparent and robust approach to the digital asset market to promote effective regulation, alignment, innovation, and risk mitigation. As the first open-source digital asset standard, ARC enables institutions to keep accurate records of highly dynamic digital assets across various dimensions. ARC contains reference and categorization details about a digital asset, such as asset names and addresses across blockchains, exchanges it trades on, spot and derivatives instruments of the asset, instrument contract specifications, and use cases. While ARC is an open-source standard, Amberdata is the primary maintainer of ARC and provides clear contribution guidelines for the larger community to contribute to and expand this digital asset security master database. ARC endpoints are updated daily and the data is also available via GitHub and analytics-friendly flat-file formats. Please see the [API Docs](/http/arc/exchange-statistics) for response field schemas. *** # ARC Instrument & Asset Resolution Process # Methodology Our complete methodology can be found in the [ARC White Paper](https://go.amberdata.io/lp-asset-reference-and-classification-methodology). *** # Data Delivery ARC can be consumed through several different mechanisms. Public access is available directly from its GitHub repository ([https://github.com/amberdata/arc](https://github.com/amberdata/arc)). In the GitHub repository, the contents of ARC are provided in JSON format to enable easy exploration and comprehension of the dataset. Customers of Amberdata can also consume ARC through REST API endpoints. The [endpoints are documented here](/http/arc/search-assets). *** # Contribution Guidelines ARC is an open-source dataset that is available to the public and thereby any user that is interested in understanding the digital asset landscape. ARC is licensed under the Apache 2.0 license. Amberdata is the main contributor and maintainer of ARC and welcomes contributions to the dataset from the larger community. To facilitate high-quality participation and collaboration, contributors must adhere to the following contribution guidelines: 1. Contributors must open individual pull requests for adding new assets, adding classification tags, and adding new instruments. This will ensure that all reviews are accurate and timely. 2. Contributors should share Amberdata’s mission and vision to make ARC an industry-leading, verified, and trusted dataset for digital asset users, which requires that contributors adhere to the Code of Conduct described in the repository. 3. All pull requests will be subject to automation and testing to ensure the quality of the changes. **Incorporation of Contributions** Once accepted and the pull request is merged, the new contributions will take up to one hour to be reflected in all of the dataset access methods for ARC. These policies are also captured in the open-source repository ([https://github.com/amberdata/arc/blob/main/CONTRIBUTION.md](https://github.com/amberdata/arc/blob/main/CONTRIBUTION.md)) *** *** # Asset Symbols FAQ Source: https://docs.amberdata.io/data-dictionary/asset-symbols-faqs ### What Are .amb.-Suffixed Symbols? In Amberdata’s aggregated metric endpoints (e.g., VWAP, TWAP, volume metrics), asset symbols may appear with an `.amb.` suffix followed by an integer (e.g., `gas.amb.1`). This suffixing system is used to disambiguate **asset collisions** across exchangesβ€”cases where multiple unrelated assets share the same symbol. An **asset collision** occurs when two or more distinct assets are listed under the same symbol on different exchanges. For example: * **Neo Gas** is listed under the symbol `GAS` on Poloniex, HTX, OKEX, and Binance. * **Gas DAO** also uses the symbol `GAS` but is listed on MEXC. Both assets trade under the instrument `gas_usdt`, but they represent entirely different entities with different market behaviors and valuations. Aggregating metrics such as VWAP or trading volume without resolving this conflict would produce inaccurate results. To handle this, Amberdata appends an `.amb.` suffix and a unique identifier (e.g., `gas.amb.1`, `gas.amb.2`) to differentiate these assets in aggregated metric endpoints. ### **Using Aggregated Metric Features** To correctly use aggregated metrics: * Query the **aggregated metrics information endpoints** to retrieve supported asset symbols and names. * These endpoints return metadata that maps the `.amb.`-suffixed asset to its corresponding exchange-specific representations. ### **Tick-by-Tick Market Data vs Aggregated Metrics** * **Tick-by-Tick Market Data** (trades, order book events/snapshots) uses **the exact asset symbol as listed on the exchange** (e.g., `lsd7` on MEXC). * **Aggregated Metrics** (VWAP, TWAP, trading volumes) use **normalized and disambiguated symbols**, which may include the `.amb.` suffix. **Important:** `.amb.`-suffixed symbols are not supported for tick-by-tick endpoints. Use the exchange-specific symbol instead. *** ### **Why Aggregated Metrics May Be Temporarily Unavailable** Amberdata employs a **human-in-the-loop asset verification process** to ensure the accuracy of aggregated metrics. When a new asset or instrument is listed: * Raw market data becomes available immediately (including trades and order book events). * Aggregated metrics become available only after the asset is reviewed and classified by Amberdata’s internal asset review committee. This verification process typically introduces a delay of up to **\~1 week** before aggregated metrics (VWAP, TWAP, etc.) are published for newly listed assets. *** ### I'm able to pull raw market data for an asset/instrument that recently got listed on an exchange, but I'm not able to get VWAP, TWAP, or other aggregated metrics for the asset/instrument? Amberdata applies a **human-in-the-loop asset review process** to verify whether newly listed instruments represent existing assets or entirely new ones. This process includes automated detection but concludes with manual validation by internal subject matter experts. As a result: * **Tick-by-tick market data** (e.g., trades, order book events, snapshots) is made available immediately upon asset listing. * **Aggregated metrics** (e.g., VWAP, TWAP, volume) are only enabled after the asset classification is completed. This review process typically results in a delay of approximately **1 week** from the time of listing to the availability of aggregated metrics. ### Will the `.amb.` suffixed symbol work for tick-by-tick market data features? No, the `.amb.` suffixed symbols only work for the aggregated metrics. For tick-by-tick data (e.g., trades, order book events, order book snapshots), use the **original exchange-specific asset symbol**, which matches the naming convention used by the exchange. * Use the **aggregated metrics information endpoints** to retrieve metadata for disambiguated symbols. * These responses include mappings of `.amb.` symbols to the corresponding native symbols per exchange. For example: ```json JSON theme={null} { "status": 200, "title": "OK", "description": "Successful request", "payload": { "metadata": { "next": null }, "data": [ { "asset": "lsd", "startDate": 1708387200000, "endDate": 1708628220000, "assetName": "L7 DEX", "marketDataReference": [ { "exchange": "huobi", "assetSymbol": "lsd" }, { "exchange": "mexc", "assetSymbol": "lsd7" } ] } ] } } ``` In this example: * The asset **L7 DEX** has the symbol `lsd` on HTX and `lsd7` on MEXC. * For aggregated metrics, use the `.amb.`-style symbol. * For tick-by-tick data, use the exact exchange-specific symbol (e.g., `lsd7` on MEXC). In order to reduce confusion when using the tick-by-tick market data features, for a given asset, **A**, Amberdata retains the exact symbol of **A** from each exchange for the instruments of **A**. Remember, an asset symbol is unique to a single exchange, but it is not unique across exchanges. *** # Addresses Source: https://docs.amberdata.io/data-dictionary/blockchain/addresses # Definition A **blockchain address**, also referred to as a **cryptocurrency address** or **public key**, is a unique alphanumeric identifier used to designate the source or destination of a blockchain-based transaction. Each address is prefixed according to the associated blockchain protocol, such as `1` for Bitcoin or `0x` for Ethereum. The address is derived from a cryptographic public-private key pair and enables interaction with the blockchain network, including the sending and receiving of assets. Blockchain addresses are pseudonymous and do not contain personally identifiable information. They function as publicly accessible endpoints that can be used to validate and record transactions on the blockchain ledger. *** # Details In the Ethereum network, a blockchain address may represent either an **externally owned account (EOA)** or a **smart contract account**. EOAs are user-controlled accounts secured by a private key, while smart contract accounts are autonomous code-based entities that execute predefined logic and may hold or transfer assets. Both account types are assigned unique Ethereum addresses. The Amberdata API supports queries using both EOA and smart contract addresses within the Blockchain Addresses namespace. Available endpoints enable access to historical and real-time data, such as account balances, balance time series, transaction histories, and address activity across supported blockchain networks. All addresses observed on supported chains can be queried to retrieve associated transactions and on-chain behaviors. *** # API Endpoints [/addresses/\{hash}/account-balances/latest](/http/blockchain/balance-latest--by-address) [/addresses/\{hash}/account-balances/historical](/http/blockchain/balance-historical--by-address) [/addresses/\{hash}/balances](/http/blockchain/balance-&-tokens-latest--by-address) [/addresses/balances](/http/blockchain/account-&-token-balances-latest-batch--multiple-wallets) [/addresses/\{hash}/logs](/http/blockchain/transaction-logs--by-wallet-address) [/addresses/\{hash}/token-balances/latest](/http/blockchain/token-balances-latest--by-address) [/addresses/\{hash}/token-balances/historical](/http/blockchain/token-balances-historical--by-address) [/addresses/\{hash}/token-transfers](/http/blockchain/token-transfers--by-wallet-address) [/addresses/\{hash}/transactions](/http/blockchain/transactions--by-address) *** # Availability The blockchain endpoints available across the various on-chain namespaces are accessible via REST API, WebSockets, or JSON-RPC. A complete list of supported blockchain networks is provided in the API documentation. Amberdata ensures access to all events from the genesis block onward. This infrastructure enables the delivery of comprehensive historical datasets across most supported blockchain networks. *** # Frequently Asked Questions **Are blockchain addresses anonymous?** * While blockchain addresses do not include personally identifiable information, they are not completely anonymous. The transactions associated with an address are recorded on the blockchain and are publicly visible, so it is possible to trace the flow of cryptocurrency between addresses.. **Can the same person have multiple blockchain addresses?** * Yes, the same person can have multiple blockchain addresses. It is common for cryptocurrency users to have multiple addresses, as this can help to improve privacy and security when sending and receiving transactions. Even if a person has multiple addresses, each address will have its unique identifier on the blockchain network. *** # Balances Source: https://docs.amberdata.io/data-dictionary/blockchain/balances # Definition A balance refers to the amount of a particular cryptocurrency or other assets that is associated with a specific address on the blockchain. On a blockchain, each address has a balance that represents the total amount of cryptocurrency or other assets that are stored at that address. The balance of an address can increase or decrease over time as transactions are executed on the blockchain. For example, if someone sends cryptocurrency to an address, the balance of that address will increase by the amount of the cryptocurrency sent. Balances are an important aspect of many blockchain systems. They enable users to track their ownership and movement of assets and are also used to enforce rules and constraints, such as ensuring that users have sufficient balances to pay for certain actions. In some cases, balances may also be used to represent non-financial assets, such as votes or other forms of digital ownership. For example, a blockchain-based governance system such as MakerDAO might use balances to represent the voting power a user has, which can be used to cast votes or enforce rules and constraints. *** # Details Amberdata provides up-to-date information on the account balances of different cryptocurrencies and tokens on a number of blockchain networks, including Ethereum, Bitcoin, Arbitrum, Optimism, Bitcoin Cash, Polygon, Litecoin, and Binance Smart Chain. This data includes the current balance of a specific account, as well as the transaction history for that account, allowing users to track the movement of funds over time. Amberdata also provides a portfolio feature that shows current balances and positions across blockchains. *** # API Endpoints [/blockchains/addresses/\{address}/portfolio](/http/blockchain/wallet-portfolio--balance-&-token-holdings) [/blockchains/addresses/\{hash}/account-balances/latest](/http/blockchain/balance-latest--by-address) [/blockchains/addresses/\{hash}/account-balances/historical](/http/blockchain/balance-historical--by-address) [/blockchains/addresses/\{hash}/balances](/http/blockchain/balance-&-tokens-latest--by-address) *** # Availability Blockchain endpoints found throughout the different on-chain namespaces are available via REST API and WebSockets. The list of supported Blockchain networks can be found in the API Documentation [here](/http/http-api-fundamentals). *** # Frequently Asked Questions **How is blockchain balance data stored on the blockchain?** * Blockchain balance data is stored in the blockchain ledger as a record of all transactions that have occurred between addresses. **What kind of blockchain balance data does Amberdata offer?** * See real-time and historical balance data for a specified address. Sort by currency, specified value ranges, and time. With the batch endpoint, view an entire portfolio's summary with a single call and get totals for ETH & all token amounts with market prices. *** # Blocks Source: https://docs.amberdata.io/data-dictionary/blockchain/blocks # Definition In a blockchain, a block is a collection of verified transactions that are bundled together and added to the blockchain in sequential order. Each block contains a block header and block data. The block header contains metadata about the block, such as a timestamp, a unique identifier (known as a "hash"), and a reference to the previous block in the chain. This reference to the previous block creates a chronological link between blocks and helps ensure the integrity of the blockchain. The data in a block is the actual set of transactions that are being added to the blockchain. These transactions include things like sending cryptocurrency from one wallet to another, executing a smart contract, or adding a new asset/token to the blockchain. The block data is represented as a digital ledger, which includes information about the sender, receiver, asset amount(s), and other relevant details. Once a block is added to the blockchain, it becomes a permanent and unalterable record that can be verified by anyone on the network. *** # Details Block data depends on the specific blockchain network, but example information includes: * **Block details**: Information about each block in a blockchain network, including its hash, timestamp, size, and transaction data. * **Transaction data**: Detailed information about transactions in a blockchain network, including sender and receiver addresses, gas used, and transaction fees. * **Token data**: Data on tokens in a blockchain network, including token balances, supply, and transaction history. * **Contract data**: For smart contract-based blockchains, we offer data on the contracts themselves, including contract address, source code, and contract events. * **Address data**: Data on addresses in a blockchain network, including balances, transaction history, and token holdings. * **Network data**: Data on various network metrics, such as network hash rate, difficulty, and mining rewards. *** # API Endpoints [/blockchains/blocks/metrics/historical](/http/blockchain/metrics-historical--confirmed-blocks) *** # Availability Blockchain endpoints across the various On-Chain namespaces are accessible via **REST API**, **WebSockets**, and **JSON-RPC**. A comprehensive list of supported blockchain networks is available in the [API Documentation](#). Amberdata enables access to all events from the genesis block onward. This infrastructure allows for the delivery of complete historical datasets across most supported blockchain protocols. *** # Frequently Asked Questions #### **What is the value of showing block data compared to address and transaction data?** Exposing block-level data in addition to address- and transaction-level data provides flexibility in how blockchain data is queried and analyzed. * For **high-level overviews**, such as total transaction count or cumulative gas usage within a block, the **block transactions endpoint** is more efficient. * For **granular analysis**, such as inspecting individual transaction inputs, outputs, or decoded logs, the **transaction hash endpoint** offers greater detail. This multi-level access supports a wide range of use casesβ€”from macro-level network analysis to low-level protocol debugging or compliance auditing. *** # Contracts Source: https://docs.amberdata.io/data-dictionary/blockchain/contracts # Definition A blockchain contract is a computer program that is stored and executed on a blockchain network. Blockchain contracts are also known as \*\*smart contracts. \*\*They are self-executing contracts that can automate the exchange of value or the execution of certain actions between parties in a transparent and tamper-proof manner. Smart contracts are written in programming languages that are compatible with the specific blockchain platform. They are stored on the blockchain and executed automatically when certain pre-defined conditions are met. The execution of a smart contract is irreversible and transparent, as all participants in the network can view the contract's code and the details of its execution. *** # Details Blockchain contracts, also known as smart contracts, eliminate the need for intermediaries or trusted third parties to oversee transaction execution. This decentralization enhances efficiency, security, and cost-effectiveness compared to traditional contract methods. The **Blockchain Contracts** namespace within Amberdata’s API enables access to comprehensive details about individual smart contracts. Available data includes contract metadata such as the contract name, bytecode, Application Binary Interface (ABI), and source code where available. Additionally, the API exposes all contract functions; if function signatures are not directly accessible, bytecode is decompiled to extract function information. *** # API Endpoints [/blockchains/contracts/\{hash}](/http/blockchain/contract-details) *** # Availability Blockchain endpoints across the On-Chain namespaces are accessible via **REST API**, **WebSockets**, and **JSON-RPC**. A complete list of supported blockchain networks is provided in the [API Documentation](https://docs.amberdata.io/reference#reference-getting-started). Amberdata maintains full nodes for supported blockchains, retaining all events from the genesis block onward. This infrastructure supports the delivery of **complete historical datasets** for most supported chains. *** # Frequently Asked Questions #### What programming languages are used to create blockchain contracts? * Programming languages for blockchain contracts vary by network. For instance, **Ethereum** smart contracts are primarily written in **Solidity**. On the **Bitcoin** network, contract-like functionality is implemented using scripting languages, with tools available in **C++**, **Python**, **Java**, and others. #### Can blockchain contracts be edited or deleted? * Once deployed on the blockchain, smart contracts are immutable; they cannot be edited or deleted. This immutability guarantees contract security and ensures that terms cannot be altered post-deployment. *** # DEX Trades Source: https://docs.amberdata.io/data-dictionary/blockchain/dex-trades # Definition The DEX Trades feature provides a unified source of detailed trading data across all decentralized exchanges and supported blockchains in the Amberdata ecosystem. It offers precise insights into trades, volumes, and liquidity trends, empowering users to analyze the dynamics of decentralized finance (DeFi). This is essential for tracking market activity, assessing trading patterns, and gaining a competitive edge in decentralized trading environments. With both real-time and historical data, it ensures a comprehensive understanding of asset performance and blockchain-specific trade behavior. *** # Details This endpoint aggregates metadata and structural information for decentralized exchanges and supported blockchains, serving as a foundational resource for analyzing the broader DeFi trading landscape. It includes exchange-specific details and blockchain-level insights. The DEX Trades feature provides: * Information on supported blockchains and their decentralized exchanges * Metadata on trading pairs, exchange volume, and activity * Continuous updates to reflect changes in the DeFi ecosystem *** # API Endpoints [/defi/dex/information](/http/defi/dex-information) [/defi/dex/trades](/http/defi/dex-trades-historical) *** # Availability DEX Trade data is available via REST API for the information and historical data. *** # Frequently Asked Questions * **Who uses DEX Trades?** * These features are widely used by quantitative traders, DeFi analysts, and developers creating analytics dashboards or trading bots. * **What blockchains are supported?** * Ethereum, Polygon, Arbitrum, BNB, Optimism, and Avalanche are currently supported. * **How much trade history do these endpoints support?** * Currently, 2 years of data on a rolling basis. *** # Lending Overview Source: https://docs.amberdata.io/data-dictionary/blockchain/lending # Definition Lending in DeFi closely parallels lending in traditional financial markets, with the key difference being the decentralized nature of the platform replacing centralized institutions such as banks. Users interact with protocols like Aave to borrow and lend specific assets at applicable borrowing and lending rates. Without a centralized authority to approve participation, the barrier to entry is significantly lower and more equitable. Access requires only a compatible wallet and connection to the protocol. Amberdata provides comprehensive data for all supported lending protocols, including borrow and lend rates, total value locked (TVL), protocol names and versions, borrow stable rates (where applicable), and other relevant parameters. Current coverage includes major lending platforms such as Aave (v1, v2, and v3), Compound, and others, with ongoing additions of new protocols. *** # Details DeFi Lending data supports various use cases including historical research, monitoring the current borrowing and lending conditions within protocols or specific pools, backtesting trading strategies, and more. *** # API Endpoints [/defi/lending/assets/information](/http/defi/lending-assets-information) [/defi/lending/\{protocolId}/protocol](/http/defi/lending-protocol) [/defi/lending/\{protocolId}/asset/\{asset}](/http/defi/lending-assets) [/defi/lending/\{protocolId}/wallet/\{walletAddress}](/http/defi/lending-wallets) [/defi/lending/\{protocolId}/governance](/http/defi/lending-governance) *** # Availability DeFi Lending endpoints are available via REST API for latest and historical (time series) data. *** *** # Lending Metrics Source: https://docs.amberdata.io/data-dictionary/blockchain/lending-metrics Multi-chain DeFi Metrics show aggregates of DeFi lending and give visibility into how wallets interact with protocols. # Definition [**Lending Protocol Summary Metrics**](/http/defi/lending-metrics-summary): Multi-chain daily aggregate insights like borrows, deposits, liquidations, and revenue for a specified lending protocol. [**Lending Asset Summary Metrics**](/http/defi/lending-assets-metrics-summary): Understand how an asset performs within a lending protocol with multi-chain aggregate metrics for a specified asset. [**Track Lending Wallet Positions**](/http/defi/lending-wallets-portfolio): Shows complete visibility into a wallet's breakout positions across lending and borrowing protocols. Understand historical balances, track lending and borrowing history, and evaluate asset exposure. *** # Details Multi-chain coverage includes Compound v2 and v3, MakerDAO, and Aave v2 and v3. | Protocol | Ethereum | Polygon | Arbitrum | Optimism | Avalanche | | ----------- | -------- | ------- | -------- | -------- | --------- | | Aave v2 | X | X | | | X | | Aave v3 | X | X | X | X | X | | MakerDAO | X | | | | | | Compound v2 | X | | | | | | Compound v3 | X | X | X | | | *** # API Endpoints [/defi/lending/\{protocolId}/metrics/summary](/http/defi/lending-metrics-summary) [/defi/lending/\{protocolId}/assets/\{assetId}/metrics/summary](/http/defi/lending-assets-metrics-summary) [/defi/lending/\{protocolId}/wallets/\{address}/portfolio](/http/defi/lending-wallets-portfolio) *** # Availability DeFi lending metrics endpoints are available via REST API for historical (time series) data and AWS S3 for bulk downloads. Sample files are available to [download here](/cloudsync/cloudsync-blockchain-data-and-defi-analytics). *** # Stablecoin Lending Metrics Source: https://docs.amberdata.io/data-dictionary/blockchain/lending-stablecoin-metrics # Definition The Stablecoin Lending Metrics endpoint provides aggregated metrics for USDT, USDC, DAI, BUSD, and TUSD across supported lending protocols on Ethereum, Arbitrum, Optimism, and Avalanche. *** # Details Stablecoins are among the most actively used assets within lending protocols and serve as a strong indicator of protocol activity and health. This endpoint aggregates lending activity data for major stablecoins, enabling insight into: * Total deposited * Total borrowed * Total repaid * Total withdrawn * Number of flash loans * Liquidated USD amounts * And more Metrics are available across all supported lending protocols, such as Aave V2, Aave V3, Compound, and Maker. The data can be queried at the hourly or daily level and supports historical lookbacks, making it suitable for tracking activity over time or correlating lending trends to macro events. For example, analysts can examine spikes in stablecoin borrowing following significant regulatory events or market shocks. This endpoint helps assess risk, liquidity trends, and comparative activity across lending protocols and chains. *** # API Endpoints [/defi/stablecoins/\{assetSymbol}/lending/metrics/summary](/http/defi/stablecoins-lending-metrics-summary) *** # Availability * **Delivery Methods**: Available via REST API and AWS S3 (for USDC and USDT). * **Chains Supported**: Ethereum, Arbitrum, Optimism, Avalanche. * **Frequency**: Queryable by hour or day. *** # Frequently Asked Questions **Does this endpoint include all lending protocols supported by Amberdata?** * Yes. It includes all supported lending protocols, such as Aave (V2 and V3), Compound, and Maker. **Is this endpoint multi-chain?** * Yes. The endpoint supports Ethereum, Arbitrum, Optimism, and Avalanche. *** # DeFi Transactions Source: https://docs.amberdata.io/data-dictionary/blockchain/lending-transactions # Definition DeFi Transaction features provide in-depth views of lending protocols and the way they operate. [**Protocol**](/http/defi/lending-protocol): Shows what is happening in the protocol over a fixed period. This may include: * Protocol actions (collateral, deposits, repays, borrows, withdraws, liquidations) * Asset IDs, asset symbols, or markets * Borrow Rates or Debts * Wallet addresses of the user or repayer. *** [**Asset/Pool**](/http/defi/lending-assets): Retrieves information about all of the actions that occurred for a specific asset on a protocol within a certain period. This may include: * Asset actions (collateral, deposits, repays, borrows, withdraws, liquidations) * User * Swaps or mints * Amount of token(s) *** [**Wallet**](/http/defi/lending-wallets): Retrieves information about the actions taken by a specific wallet/user on the protocol within a certain period. This may include: * Wallet actions (collateral, deposits, repays, borrows, withdraws, liquidations) * Borrow Rates or Debts * Transaction amounts * Asset IDs, asset symbols, or markets *** [**Governance:**](/http/defi/lending-governance) Retrieves information about the governance actions that occurred for the protocol within a period. This may include: * Vote support (true or false) * Voting Power * User * Proposal ID or description *** # Details Not every lending protocol has every lens, and different exchanges may use differing terminology. For example, the **Asset lens for Aave** is the structural equivalent of the **Pool lens for Uniswap v2**, since Uniswap uses asset pairs (asset\_asset) to create a pool. *** # API Endpoints [/defi/lending/\{protocolId}/protocol](/http/defi/lending-protocol) [/defi/lending/\{protocolId}/assets/\{asset}](/http/defi/lending-assets) [/defi/lending/\{protocolId}/wallets/\{walletAddress}](/http/defi/lending-wallets) [/defi/lending/\{protocolId}/governance](/http/defi/lending-governance) *** # Availability DeFi Lens endpoints are available via REST API for historical (time series) data, which goes back to the creation date of the lending protocol. *** *** # Logs Source: https://docs.amberdata.io/data-dictionary/blockchain/logs # Definition Logs record events that occur on the blockchain, including the creation of a new block, the execution of a smart contract function, or the transfer of cryptocurrency between two wallets. Logs are typically stored in a separate data structure within the blockchain and can be used by developers to build complex applications. *** # Details Logs data is available from multiple endpoints, including addresses, blocks, and contracts. *** # API Endpoints [/blockchains/addresses/\{hash}/logs](/http/blockchain/transaction-logs--by-wallet-address) *** # Availability Logs features are available via REST API or Cloudsync. The list of supported Blockchain networks can be found in the API Documentation [here](/http/http-api-fundamentals). *** # Metrics - Blockchain Source: https://docs.amberdata.io/data-dictionary/blockchain/metrics # Definition Blockchain metrics are quantitative measures that are used to analyze and assess the performance and behavior of a blockchain network. Metrics can provide valuable insights into the health, security, and scalability of the network, as well as the overall activity and usage of the network by its users. *** # Details * **Blockchain Address Metrics**: active address count for a given blockchain, historical adoption and usage for a specified address on Ethereum, etc. * **Blockchain Block Metrics**: average block difficulty in mining, average time needed to confirm a block, average hashrate used in mining, total size of block data confirmed, total transaction fees paid to miners, and more * **Blockchain Token Metrics**: total amount of token transfers, the historical velocity and number of transfers for the specified address, etc. * **Blockchain Transaction Metrics**: average amount of transaction fees, total amount of transactions, total number of contract function calls confirmed in the transactions, average gas price used in the transactions, and more *** # API Endpoints [/blockchains/metrics/latest](/http/blockchain/metrics--by-blockchain) [/blockchains/blocks/metrics/historical](/http/blockchain/metrics-historical--confirmed-blocks) [/blockchains/tokens/metrics/\{symbol}/historical](/http/blockchain/token-metrics-historical) [/blockchains/transactions/metrics/latest](/http/blockchain/metrics-latest--confirmed-transactions) [/blockchains/transactions/metrics/historical](/http/blockchain/metrics-historical--confirmed-transactions) *** # Availability Blockchain-related endpoints across the On-Chain namespaces are accessible via REST API, WebSockets, and JSON RPC. A complete list of supported blockchain networks is available in the API Documentation [here](/http/http-api-fundamentals). *** # Frequently Asked Questions **How are blockchain metrics used and why are they important?** * Blockchain metrics are essential for understanding the health, performance, and user behavior within a blockchain network. These metrics can help analysts, researchers, and institutional participants identify trends, evaluate network activity, and support decision-making processes. The relevance of a specific metric may vary depending on the context or use case, and not all metrics carry equal weight in every analytical scenario. *** # DeFi OHLCV Source: https://docs.amberdata.io/data-dictionary/blockchain/ohlcv # Definition OHLCV (Open, High, Low, Close, and Volume) is an aggregated dataset consisting of five core data points. The **Open** and **Close** represent the first and last price levels within a given time interval, respectively. The **High** and **Low** reflect the maximum and minimum price levels observed during that same interval. **Volume** indicates the total quantity of assets traded within the specified period. This data is commonly visualized through candlestick charts to support technical analysis on intraday values. OHLCV data is available with minute, hourly, or daily granularity. Amberdata pioneered **DeFi OHLCV** by establishing a consistent methodology for aggregating decentralized exchange data. Due to the absence of a standardized "end of trading day" in crypto markets, comparing trading pairs across centralized and decentralized venues can be challenging. Amberdata standardizes volume normalization using 12:00 AM UTC as the end-of-day (EOD) for decentralized exchanges and lending protocols. This enables consistent cross-exchange comparison and supports arbitrage strategies. *** # Details OHLCV price values are expressed in the **quote asset**, while the volume is expressed in the **base asset**. For instance, in a BTC-USD pair, price values are denominated in USD and volume in BTC. *** # API Endpoints ## DeFi OHLCV [/market/defi/ohlcv/information](/http/defi/dex-ohlcv-information) [/market/defi/ohlcv/\{pool}/latest](/http/defi-market/dex-ohlcv-latest) [/market/defi/ohlcv/\{pool}/historical](/http/defi-market/ohlcv-historical) *** # Availability OHLCV data is accessible via REST API for historical time series and via WebSockets for real-time streaming. *** # Frequently Asked Questions **What is OHLCV used for?** * OHLCV provides a normalized view of trading activity across crypto ecosystems. It is commonly used to evaluate market structure, momentum, and to support arbitrage strategies between centralized and decentralized exchanges. **Why is DEX OHLCV unique?** * Decentralized trading occurs across multiple liquidity pools and exchanges, each with its own pricing dynamics. DEX OHLCV aggregates prices across all relevant liquidity pools, incorporating volume-weighted and time-weighted average price calculations (VWAP and TWAP). This results in more accurate pricing reflective of decentralized market conditions. **How are OHLCV values generated?** * OHLCV values are derived from underlying DEX trade data. On top of this data, additional calculations such as Price, TWAP, and VWAP are produced, following methodologies consistent with those used in centralized spot market data pipelines. *** # Lending Portfolio & Returns Source: https://docs.amberdata.io/data-dictionary/blockchain/portfolio-returns # Definition This data provides a detailed overview of a specific wallet address's activity and position within popular decentralized lending protocols. For a given user's address participating in any of these lending platforms, we give the ability to look at the total amount they've deposited into the protocol, total amount of collateral they've supplied to the protocol, total amount they've borrowed, total amount they can still borrow, the difference between total collateral and total borrowed, total amount of protocol incentives they've generated by participating in the protocol, total amount of protocol incentives they have not yet claimed, a risk metric that indicates how close they are to being liquidated, the maximum loan value, the limit at which they are considered under-collateralized, and the collection of all lending and borrowing positions that this address holds broken down by asset *** # Details Accessing this data via a single API endpoint is immensely valuable for several reasons: * **Comprehensive Oversight:** It provides a holistic view of an address's activity within a specific decentralized lending protocol. This allows for efficient monitoring and management of risk, lending, and borrowing activities. * **Risk Management:** With metrics like the risk of liquidation, maximum loan value, and the limit of undercollateralization, users or automated systems can make timely decisions to prevent liquidation or optimize returns. * **Incentive Tracking:** Information on generated and unclaimed protocol incentives enables users to claim rewards optimally, thereby maximizing yield. This kind of data aggregation simplifies complex DeFi interactions, making it easier for users to engage with lending protocols more effectively. *** # API Endpoints [/defi/lending/\{protocolId}/wallets/\{address}/portfolio](/http/defi/lending-wallets-portfolio) *** # Availability The Lending Wallets endpoint is available via REST API for historical (time-series) data with history as far back as the blockchain's genesis block. Support includes **Aave v2 & v3**, **Compound v2 & v3** and **MakerDAO** across **Ethereum, Polygon, Avalanche, Arbitrum,** and **Optimism**. *** # Frequently Asked Questions * **What is DeFi Lending?** * DeFi (Decentralized Finance) lending refers to the practice of lending assets through blockchain-based platforms without the need for traditional financial intermediaries like banks. Some of the more popular Lending platforms are Aave, Compound, and MakerDAO. * **What is collateral?** * Collateral is the asset locked in a smart contract when a loan is taken out. If a borrower fails to repay, the collateral can be liquidated to cover the debt. If the value of the collateral drops below a certain threshold, it may be sold off automatically to repay the loan. * **How is the Interest Rate determined?** * Interest rates on DeFi lending platforms are often determined algorithmically, based on supply and demand for a particular asset. *** # Token Transfers Source: https://docs.amberdata.io/data-dictionary/blockchain/token-transfers # Definition A blockchain transferβ€”more specifically, a token transferβ€”is the movement of a token on a blockchain (such as Ethereum) from one address to another within a transaction. For example, sending SHIB tokens from one wallet to another constitutes a token transfer. *** # Details Amberdata’s API enables flexible querying of token transfers through multiple access points, including by address, block, transaction hash, or specific token (e.g., DAI). This allows users to tailor their queries according to their analytical needs, from high-level overviews at the block level to granular details at the transaction hash level. Users can also isolate transfers for a particular token across supported chains, facilitating focused analysis. For instance, one can retrieve all DAI transfers within a specific time frame and compare them against USDC transfers during the same period, leveraging the token transfers endpoints within the Token namespace. *** # API Endpoints [/blockchains/addresses/\{hash}/token-transfers](/http/blockchain/token-transfers--by-wallet-address) [/blockchains/tokens/\{hash}/transfers](/http/blockchain/token-transfers--by-token-address) *** # Availability Amberdata’s Transfers endpoints are accessible via REST API, WebSockets, and JSON RPC across various On-Chain namespaces. A complete list of supported blockchain networks can be found in the Amberdata API documentation. [here](/http/http-api-fundamentals). *** # Frequently Asked Questions **Which token standards are supported for transfer data on Ethereum?** * Amberdata supports token transfers for ERC-20, ERC-721, ERC-777, ERC-884, ERC-998, and ERC-1155 standards. **What additional information is included in the transfer endpoint responses?** * Depending on the specific endpoint, responses may include token name, symbol, timestamp, token type, sender and recipient addresses, and other relevant metadata. *** *** # Tokens Source: https://docs.amberdata.io/data-dictionary/blockchain/tokens # Definition Blockchain tokens are digital assets that are created and managed on a blockchain like Ethereum. They can be thought of as units of value that are stored and transferred on a particular blockchain. Tokens can be used for a variety of purposes, such as representing assets or rights (like NFTs), enabling access to a network or service, or functioning as a medium of exchange. Tokens are created and managed through the use of smart contracts on the blockchain, which are self-executing contracts with the terms of the agreement between buyer and seller being directly written into the code itself. The tokens can be stored in a digital wallet, and their transfer and ownership can be tracked on the blockchain ledger. *** # Details Amberdata provides a wide array of token data, including: * **Token Information**: Comprehensive token information for various tokens, including token name, symbol, contract address, decimals, total supply, circulating supply, and more. * **Token Transfers**: Data on all token transfer,s including the sender, receiver, amount, transaction hash, and timestamp. * **Token Holders**: Information on token holders, including the number of holders, their addresses, and the number of tokens held by each address. * **Token Analytics**: Token analytics data such as price, volume, market cap, trading volume, and more. *** # API Endpoints [/blockchains/addresses//portfolio](/http/blockchain/wallet-portfolio--balance-&-token-holdings) [/blockchains/addresses//balances](/http/blockchain/balance-&-tokens-latest--by-address) [/blockchains/addresses//token-balances/latest](/http/blockchain/token-balances-latest--by-address) [/blockchains/addresses//token-balances/historical](/http/blockchain/token-balances-historical--by-address) [/blockchains/addresses//token-transfers](/http/blockchain/token-transfers--by-wallet-address) [/blockchains/tokens//transfers](/http/blockchain/token-transfers--by-token-address) [/blockchains/tokens//holders/latest](/http/blockchain/current-holders--by-token-address) [/blockchains/tokens/metrics//historical ](/http/blockchain/token-metrics-historical) [/blockchains/tokens//supplies/historical](/http/blockchain/historical--token-supplies-by-address) [/blockchains/tokens//transfers](/http/blockchain/token-transfers--by-token-address) *** # Availability Amberdata’s Token endpoints, available across various On-Chain namespaces, can be accessed via REST API, WebSockets, or JSON RPC. A comprehensive list of supported blockchain networks is provided in the API documentation. *** # Frequently Asked Questions **Does the data include the most recent and historical token data?** * Yes. Depending on the specific endpoint, Amberdata provides both the latest token data (reflecting the most recent block) and historical data extending back to the genesis block for most supported chains. *** # Transactions Source: https://docs.amberdata.io/data-dictionary/blockchain/transactions # Definition A blockchain transaction is a transfer of value or data from one participant to another within a blockchain network. In a blockchain, transactions are stored in blocks, which are connected in a linear, chronological chain, hence the name "blockchain". When a transaction occurs on a blockchain, it is first broadcast to the network, where it is verified and validated by the nodes or computers that participate in the network. Once a consensus is reached among the nodes, the transaction is recorded in a block, which is then added to the blockchain. A typical blockchain transaction contains the following information: * **Sender address**: The address of the participant who initiates the transaction. * **Recipient address**: The address of the participant who receives the transaction. * **Amount**: The value or quantity of the asset or data being transferred. * **Transaction fee**: The fee paid by the sender to incentivize the network to process the transaction. * **Timestamp**: The date and time when the transaction occurred. * **Transaction hash**: A unique identifier that is generated for each transaction. *** # Details Amberdata offers comprehensive transaction data through its transactions endpoints, covering all relevant details such as sending and receiving addresses (including token transfers), fees (gas), amounts, op codes, block numbers, block hashes, timestamps, and more. These endpoints provide flexible granularity, allowing users to query data at the transaction hash level, address level, or block level depending on their specific needs. This versatility means that Amberdata’s transaction endpoints can often fulfill data requirements within a single query, eliminating the need to use multiple tools or navigate complex menus to retrieve the desired information. *** # API Endpoints [/blockchains/addresses/\{hash}/transactions](/http/blockchain/transactions--by-address) β€” currently available for `ethereum-mainnet`. *** # Availability The transactions endpoints are accessible via REST API, WebSockets, and JSON RPC across multiple on-chain namespaces. A full list of supported blockchains is available in the Amberdata API documentation [here](/http/http-api-fundamentals). *** # Frequently Asked Questions **What are the benefits of granular transaction data?** * Granular transaction data enables diverse applications, including research and back-testing, accounting, tax reporting, and other use cases requiring detailed blockchain activity analysis. **What types of transaction data are included in API responses?** * API responses include all addresses involved in the transaction, gas price and gas used, transaction hash, nonce, number of confirmations, timestamp, and additional relevant metadata. *** # CloudSync Subscription Source: https://docs.amberdata.io/data-dictionary/cloudsync-subscription The columns (besides Data Type Tags) are the SKUs available with a subscription. If a SKU column cell is **empty** for a dataset i.e. `Daily Address Activity` for `Wallet Intelligence`, it means that the dataset is **not** part of that SKU. If a SKU column cell is **filled** for a dataset i.e. `ETF Holding ($)` for `Market Insights`, the values of the cell indicate which bulk delivery options are available for the dataset. For the aforementioned example, *Snowflake*. And looking at another example, *Snowflake* for `Options Decorated Trades` in `Derivatives Analytics`.