Protocols API - Messari Docs

Available Endpoints

The Protocols API is organized into the categories below:

Core Protocols

List All Protocols - Returns a complete list of all available protocols supported by Messari, along with core metrics.
List Protocols Core Metrics - Returns a list of timeseries core metrics available for all protocols.
Get Protocol Core Timeseries - Returns timeseries data for a specific protocol’s core metrics.

DEX Protocols

List DEX Protocols - Returns all available DEX protocols supported by Messari.
List DEX Metrics - Returns a list of timeseries metrics available for DEXs.
Get DEX Timeseries - Returns timeseries data for a specific DEX protocol.
Get All DEX Time Series - Returns one timeseries per DEX protocol, for every DEX protocol, in a single response.

Lending Protocols

List Lending Protocols - Returns all available lending protocols supported by Messari.
List Lending Metrics - Returns a list of timeseries metrics available for lending protocols.
Get Lending Timeseries - Returns timeseries data for a specific lending protocol.
Get All Lending Time Series - Returns one timeseries per lending protocol, for every lending protocol, in a single response.
List Lending Instance Metrics - Returns a list of timeseries metrics available at instance grain.
Get Lending Instances Timeseries - Returns one timeseries per instance of a lending protocol.
List Lending Markets - Returns a filterable list of individual lending markets.
List Lending Market Metrics - Returns a list of timeseries metrics available at market grain.
Get Lending Markets Timeseries - Returns one timeseries per market of a lending protocol.

DATs

Digital asset treasury (DAT) companies are public companies holding crypto on their balance sheet. They are not DeFi protocols, so a DAT is keyed by its stock ticker (MSTR) rather than a protocol slug, and its data comes at two grains: the company’s own capital structure, and its holdings broken out per asset.

List DATs - Returns one row per digital asset treasury company, with the assets it holds and its latest treasury values.
List DAT Metrics - Returns the metric catalog for both DAT datasets, treasury and holdings, in one response.
Get DAT Treasury Time Series - Returns one company’s capital structure history.
Get All DATs Time Series - Returns one treasury timeseries per company, for every company, in a single response.
Get DAT Holdings Time Series - Returns one company’s holdings history, one timeseries per asset it holds.
Get All DAT Holdings Time Series - Returns every company’s holdings history, one timeseries per company and held asset, in a single response.

ETFs

Crypto exchange-traded funds are covered at two grains, and they are independent cuts, not a parent and a child: one series per issuer (blackrock), and one series per underlying crypto asset (bitcoin). They ship as two sibling collections, so neither nests inside the other.

List ETF Providers - Returns one row per crypto ETF issuer, with the issuer’s latest values.
List ETF Metrics - Returns the metric catalog for both ETF datasets, provider and asset, in one response.
Get ETF Provider Time Series - Returns one issuer’s history.
Get All ETF Providers Time Series - Returns one timeseries per issuer, for every issuer, in a single response.
List ETF Assets - Returns one row per underlying crypto asset held through ETFs, with the asset’s latest values.
Get ETF Asset Time Series - Returns one underlying asset’s ETF history.
Get All ETF Assets Time Series - Returns one timeseries per underlying asset, for every asset, in a single response.

TCG

Trading-card and collectibles platforms are covered per platform and chain. A platform is keyed by its Blockworks Research slug (courtyard), and a series is keyed by the platform and the chain together (courtyard_polygon), because a platform running on more than one chain reports separately on each.

List TCG Platforms - Returns one row per trading-card platform, each with the chains it runs on.
List TCG Metrics - Returns the metric catalog for the TCG overview dataset.
Get TCG Platform Time Series - Returns one platform’s history, one timeseries per chain it runs on.
Get All TCG Platforms Time Series - Returns one timeseries per platform and chain, across every platform, in a single response.

Interoperability Protocols

List Interoperability Protocols - Returns all available interoperability (bridging) protocols supported by Messari.
List Interoperability Metrics - Returns a list of timeseries metrics available for interoperability protocols.
Get Interoperability Timeseries - Returns timeseries data for a specific interoperability protocol.

Liquid Staking Protocols

List Liquid Staking Protocols - Returns all available liquid staking protocols supported by Messari.
List Liquid Staking Metrics - Returns a list of timeseries metrics available for liquid staking protocols.
Get Liquid Staking Timeseries - Returns timeseries data for a specific liquid staking protocol.

Lending and DEX metrics

Lending and DEX protocols carry the additional metrics below. Coverage varies by protocol: not every protocol reports every field, and one that does not returns null. Check for null rather than assuming a value is present.

Lending

Available on List Lending Protocols and on Get Lending Timeseries at 1d and 1w granularity.

Field	Definition
`depositsUsd`	Value deposited with the lending protocol, in USD.
`borrowedUsd`	Total value of assets borrowed from the protocol, in USD.
`interest24HourUsd`	Interest paid by borrowers, in USD.
`netInterestIncome24HourUsd`	Interest earned less the interest paid out to depositors, in USD.
`flashLoanFees24HourUsd`	Fees earned on flash loans, in USD.
`liquidationFees24HourUsd`	Fees earned on liquidations, in USD.
`royalties24HourUsd`	Royalties paid to the protocol, in USD.
`revenueUsd`	Daily lending revenue in USD: net interest income plus flash loan, liquidation and royalty fees. Timeseries only.

depositsUsd is a balance and carries no 24Hour qualifier, so it aggregates as an average over a longer granularity. The existing netDeposits24HourUsd is a daily flow, and the two are not interchangeable. Likewise flashLoanFees24HourUsd is a fee, while the existing flashLoanVolume24HourUsd on DEX protocols is a volume.

revenueUsd is the Blockworks Research lending revenue. It is not revenue24HourUsd, which comes from a different source and is served by the core protocol and network endpoints. The two measure different things and report different values for the same protocol on the same day. Keep them apart.

Lending grains

Lending data is served at three grains. Each one is a separate dataset with its own metrics and its own route:

Dataset	Grain	Example	Metrics
`lending`	Protocol	Aave	16
`lending-instances`	Product on a chain	aave-v3 on ethereum	10
`lending-markets`	Individual pool	an aave-v3 pool on ethereum	3

The two finer grains return many series in one response, so their shape differs from both single-protocol routes and from Get All Lending Time Series, which keys each series on a protocol object instead of on dimensions. Here each entry carries its own id and its own dimensions, and metadata.pointSchemas names the columns of every points row:

{
  "data": {
    "series": [
      {
        "id": "aave_aave-v3_arbitrum_0x794a61358d6845594f94dc1db02a252b5b4814ad",
        "marketName": "arbitrum-core",
        "productSlug": "aave-v3",
        "chain": "arbitrum",
        "points": [[1748736000, 1553455825.6, 794874331.0, 758581494.6]]
      }
    ]
  },
  "metadata": {
    "pointSchemas": [
      { "name": "Timestamp", "slug": "time", "is_timestamp": true },
      { "name": "Deposits (USD)", "slug": "depositsUsd", "is_timestamp": false },
      { "name": "Borrowed (USD)", "slug": "borrowedUsd", "is_timestamp": false },
      { "name": "TVL (USD)", "slug": "tvl24HourUsd", "is_timestamp": false }
    ],
    "granularity": "1d",
    "seriesCount": 23
  }
}

marketName is present on the lending-markets dataset only. Both finer grains serve 1d only. The protocol grain still serves 1d and 1w.

Blockworks Research maps a fraction of lending protocols. A protocol it does not map returns 200 with an empty series list, not a 404. A 404 means the identifier is not a Messari protocol at all. Note also that a product slug is not a protocol identifier: pass aave, not aave-v3.

Finding instances and markets

List Lending Protocols carries an instances array on each protocol, so you can see which products and chains a protocol reports before you request a timeseries:

"lending": {
  "depositsUsd": 29279393027.2,
  "instances": [
    { "productSlug": "aave-v2", "chain": "ethereum" },
    { "productSlug": "aave-v3", "chain": "ethereum" }
  ]
}

The array is empty for a protocol that Blockworks Research does not map. Instances need no listing of their own, because the per-protocol route returns all of them. Markets do: their ids are pool addresses, and there are thousands. Use List Lending Markets to discover them, filtered by protocol, product or chain. The protocol object on each row is the parent protocol, so its slug passes straight back as the protocol filter. The specific product is the sibling productSlug field, which the product filter matches:

{
  "marketId": "aave_aave-v3_arbitrum_0x794a61358d6845594f94dc1db02a252b5b4814ad",
  "marketName": "arbitrum-core",
  "productSlug": "aave-v3",
  "chain": "arbitrum",
  "protocol": { "id": "675b85dc-…", "name": "Aave", "slug": "aave" }
}

marketId is a composite of parent slug, product slug, chain and market key. It is keyed on the pool address rather than the market name, so it survives an upstream rename. Some source rows carry no name; marketName is then the market key, and it can be an empty string.

Response caps

A single request returns at most 100 instance series or 250 market series. Above that the request returns 400 and names the filters that narrow it. Pass product and chain to the markets timeseries route to stay under the cap — a large protocol such as Euler or Morpho needs them.

DEX

Available on List DEX Protocols and on Get DEX Timeseries at 1d and 1w granularity.

Field	Definition
`correlatedVolume24HourUsd`	Volume traded between correlated assets, in USD.
`aggregatorVolume24HourUsd`	Volume the exchange received through aggregators, in USD.
`platformVolume24HourUsd`	Volume traded directly on the exchange’s own front end, in USD.
`aggregatorTradeCount24Hour`	Number of trades the exchange received through aggregators.
`platformTradeCount24Hour`	Number of trades made directly on the exchange’s own front end.

DEX volume splits

Three more DEX fields are available on the listing endpoint only, not on the timeseries endpoints:

Field	Definition
`memecoinVolumeShare`	Share of 24 hour volume traded in memecoins, as a fraction between 0 and 1 — not a percentage.
`volumeByCategory`	24 hour volume split across asset categories, in USD.
`volumeByPair`	24 hour volume split across trading pairs, in USD.

volumeByCategory has the keys nativeStablecoin, chainToken, foreignToken, stablecoinSwaps, lstSwaps, composites, tokenizedAssets, projectTokens and memes. volumeByPair has the keys bitcoinUsd, ethereumUsd, solanaUsd, avalancheUsd, bnbUsd, bitcoinEthereum, bitcoinSolana, ethereumSolana, fx and eurUsd. Both objects are omitted entirely for a protocol that reports no split at all. Within an object that is present, a category or pair with no reported volume is null. An absent object and a null value therefore carry different meanings: the first means the protocol reports no split, the second means the protocol reports a split but not for that one category or pair.

Digital asset treasury companies

DAT data is served at two grains. Each is a separate dataset with its own metrics and its own route:

Dataset	Grain	Example series key	Metrics
`treasury`	Company	`MSTR`	16
`holdings`	Company and held asset	`MSTR_btc`	3

Both serve 1d only. Every route exists in a one-entity and an all-entities form, so a full sweep of either grain is a single request rather than one call per company.

Identifiers

A DAT’s id is its stock ticker, not a protocol slug. The per-company routes accept either the ticker or the company’s Messari project slug.

Identifiers are case-sensitive. MSTR and micro-strategy both resolve; mstr returns 404. A ticker is upper-case and a slug is lower-case, so pass each one as the API stores it.

Not every company maps to a Messari project. Where none exists, slug is an empty string and projectId is absent — the company is still returned with full treasury data.

Holdings and `assetSymbol`

A holdings series is keyed on companyTicker_assetSymbol, and both halves are published beside the composite id so you never have to split it:

{
  "id": "MSTR_btc",
  "name": "Strategy BTC",
  "companyTicker": "MSTR",
  "assetSymbol": "btc",
  "networkSlug": "bitcoin"
}

assetSymbol is a lower-cased ticker symbol (btc, eth, hype), not a Messari asset slug such as bitcoin. It is lower-cased so that companyTicker + _ + assetSymbol reconstructs the series id exactly. networkSlug is a genuine slug, but it is null for some assets, so it is not a substitute.

The listing’s assetSymbol filter narrows to companies holding a given asset, and matches either casing. Each row also carries a holdings summary naming every asset the company holds, so you can see the by-asset coverage before calling the holdings routes.

Latest values on the listing

The listing reports each company’s most recent treasury point from the last 30 days. A company that reported nothing in that window returns null values and a null asOfTime, rather than a stale figure presented as current. Always read asOfTime to see which you got.

Crypto ETFs

ETF data is served at two grains. Unlike the DAT grains above, neither is a child of the other — they are two independent cuts of the same Blockworks Research data, so they are two sibling collections with a dataset each:

Collection	Grain	Example series key	Metrics
`/protocols/etfs`	Issuer	`blackrock`	8
`/protocols/etfs/assets`	Underlying crypto asset	`bitcoin`	25

Both publish a single dataset slugged overview and serve 1d only. Because both use the same dataset slug, the combined metrics endpoint carries a grain on each entry (providers or assets) to tell them apart. Every route exists in a one-entity and an all-entities form, so a full sweep of either grain is a single request rather than one call per issuer or asset.

ETF issuers are asset managers, not DeFi protocols. Their placement under /protocols is pragmatic — it keeps them beside the other Blockworks Research collections — but an ETF provider is not a protocol and carries no protocol metrics.

Identifiers

An issuer’s id is its Blockworks Research provider slug (blackrock), and an underlying asset’s id is its asset symbol (bitcoin). Both per-entity routes also accept the Messari slug mapped onto the entity, so either resolves to the same series:

GET /metrics/v2/protocols/etfs/bitwise/metrics/overview/time-series/1d
GET /metrics/v2/protocols/etfs/bitwise-asset-management/metrics/overview/time-series/1d

Not every entity maps to a Messari record. Where none exists, slug is an empty string and only the id resolves — the entity is still returned with full data.

Reading a point

A point is a timestamp followed by one value per metric, in the order metadata.pointSchemas declares. The metric slugs are the same kebab-case slugs the metrics catalog publishes, so a pointSchemas entry names the column beside it:

{
  "metadata": {
    "granularity": "1d",
    "pointSchemas": [
      { "slug": "time", "name": "Timestamp", "is_timestamp": true },
      { "slug": "aum-usd", "name": "AUM (USD)" },
      { "slug": "flow-usd", "name": "Flow (USD)" }
    ]
  }
}

On the two all-entities endpoints pointSchemas sits once in metadata, not per entity: every series in the response reads the same dataset.

Latest values on the listings

Both listings report each entity’s most recent point from the last 30 days. An entity that reported nothing in that window returns null values and a null asOf, rather than a stale figure presented as current. Always read asOf to see which you got. Sorting on a metric orders on that latest value. A row with no value for the sort metric always sorts last, in either direction — a missing AUM is not an AUM of zero, so it never leads an ascending sort.

Every ETF metric is sourced from Blockworks Research.

Trading card platforms

Trading-card and collectibles (TCG) platforms sell and trade digital collectibles, often backed by graded physical cards. They are covered at a single grain — one series per platform and chain — and publish one dataset, slugged overview, at 1d only. A platform that runs on more than one chain reports separately on each, so it has one series per chain rather than one series overall.

Nothing is aggregated across a platform’s chains, and you should not aggregate it yourself. dauNew, dauRecurring, dauTotal and uniqueBuyers are distinct counts of users, and a user active on two chains is counted on both — so summing them across chains overstates the total. topSaleUsd is a maximum, not a sum, so adding it across chains is meaningless too.

Identifiers

Two identifiers appear, and they are not interchangeable:

Field	Where	Example	What it is
`id` on a listing row	`/protocols/tcg`	`courtyard`	The platform. This is the `platformIdentifier` the platform time series route takes.
`id` on a `chains` entry, and on a series	both	`courtyard_polygon`	The platform-chain pair. This is the series key.

The series key is a composite of the two, but never split it yourself — either half may itself contain an underscore. Every series carries platform and chain as their own fields for exactly this reason:

{
  "id": "courtyard_polygon",
  "platform": "courtyard",
  "chain": "polygon",
  "points": []
}

That is also how the listing and the series join: a chains[].id from the listing matches the id of a series one-for-one. A platform slug the listing does not serve returns 404, rather than an empty series list.

The chains array

Every listing row carries a chains array, whether the platform runs on one chain or several. Read it rather than assuming a single chain — the array is the shape in both cases, so no consumer needs to special-case the multi-chain platforms. Paging is over platforms, not over platform-chain pairs, so a multi-chain platform is never split across two pages.

Messari mappings

projectSlug on a platform and networkSlug on a chain are the Messari mappings. Both are null where no Messari record maps to the entity. They are null, never an empty string, so a missing mapping is never mistaken for a real but blank slug.

Reading a point

A point is a timestamp followed by one value per metric, in the order metadata.pointSchemas declares. pointSchemas sits once in metadata, not per series: every series in the response reads the same dataset. Both time series routes return the same multi-series shape. The per-platform route is only a narrowing of the all-platforms one, so a consumer can read either with the same code.

Every TCG metric is sourced from Blockworks Research.

Key Features

Multi-Chain Aggregation: Protocol data aggregates all deployments across multiple blockchain networks (e.g., Uniswap includes V3, V2, and V1)
Comprehensive Metrics: Access volume, TVL, fees, and other key protocol metrics
Flexible Time Ranges: Query data with various granularities from 1-minute to 1-year intervals
Historical Data: Access historical protocol performance data for analysis and tracking

Use Cases

The Protocols API enables developers to:

Build DeFi analytics dashboards tracking protocol performance
Compare metrics across different protocols and protocol types
Monitor DEX trading volumes and liquidity trends
Track lending protocol utilization and interest rates
Create alerts based on protocol metric thresholds
Analyze protocol growth and adoption over time

​Available Endpoints

​Core Protocols

​DEX Protocols

​Lending Protocols

​DATs

​ETFs

​TCG

​Interoperability Protocols

​Liquid Staking Protocols

​Lending and DEX metrics

​Lending

​Lending grains

​Finding instances and markets

​Response caps

​DEX

​DEX volume splits

​Digital asset treasury companies

​Identifiers

​Holdings and assetSymbol

​Latest values on the listing

​Crypto ETFs

​Identifiers

​Reading a point

​Latest values on the listings

​Trading card platforms

​Identifiers

​The chains array

​Messari mappings

​Reading a point

​Key Features

​Use Cases

Available Endpoints

Core Protocols

DEX Protocols

Lending Protocols

DATs

ETFs

TCG

Interoperability Protocols

Liquid Staking Protocols

Lending and DEX metrics

Lending

Lending grains

Finding instances and markets

Response caps

DEX

DEX volume splits

Digital asset treasury companies

Identifiers

Holdings and `assetSymbol`

Latest values on the listing

Crypto ETFs

Identifiers

Reading a point

Latest values on the listings

Trading card platforms

Identifiers

The chains array

Messari mappings

Reading a point

Key Features

Use Cases