For the complete documentation index, see llms.txt. This page is also available as Markdown.

Index Constituents

Overview

An index constituent is a member of an index. For a multi-asset crypto index, a constituent is a cryptoasset, and its weight is the share of the index that the asset accounts for at that moment. Constituent data answers the question behind every index level: what is actually in this index right now, and in what proportion?

Constituents are the transparency layer of the Coin Metrics Bletchley Indexes (CMBI) and of the third-party index series that Coin Metrics distributes. Portfolio managers use them to replicate an index, risk teams use them to decompose index exposure into asset exposure, and researchers use the weight history to see how a basket's composition drifted and rebalanced over time.

Index constituents are accessed over the HTTP endpoint /timeseries/index-constituents.

At a Glance

Data type
Entities
Frequency / cadence
Unit
Primary endpoint
Coverage

Index constituents and weights

Indexes (single-asset, multi-asset, momentum, mining, total market, and distributed third-party series)

Hourly for indexes with changing weights. frequency accepts 1h, 1d, 1d-ny-close, 1d-ny-midday, 1d-sg-close

Weight as a decimal fraction of the index, summing to 1

/timeseries/index-constituents

🔗

Schema

One observation is the full constituent set of a single index at a single timestamp. The constituents array holds one entry per member asset, sorted by asset.

Field
Type
Description
Notes

index

string

Name of the index.

Required

time

string (date-time)

The time in ISO 8601 date-time format. Always with nanoseconds precision.

Required. The instant the composition applies to

constituents

array[object]

The member assets of the index and their weights at time.

Required. One entry per constituent, sorted by asset

Each entry in constituents carries these sub-fields:

Sub-field
Type
Description
Notes

asset

string

Unique name of the asset.

Always present. A Coin Metrics asset ID for CMBI indexes, and the provider's own symbol for third-party indexes

weight

string (decimal)

The weight of the constituent.

Always present. A decimal fraction of the index (see How weights are produced)

price

string (decimal)

The price of the constituent.

Third-party indexes only

quantity

string (decimal)

The quantity of the constituent.

Third-party indexes only

weight_basis_value

string (decimal)

The weight basis value of the constituent.

Third-party indexes only

Conventions. Weights and prices are returned as JSON strings to preserve precision. Timestamps are UTC ISO-8601 with nanosecond resolution, and time is the instant the composition applies to rather than the start of a window. Weights are decimal fractions of the index, not percentages, and the weights within one observation sum to 1 up to rounding in the last digits. Constituents are sorted by asset within each observation.

Methodology

How weights are produced

For a market-capitalization-weighted index, a constituent's weight is its share of the index's total market capitalization. At the same instant that an index level is computed, each constituent's index-eligible supply is valued at its US dollar reference rate, and the weight is that value divided by the sum across all constituents:

wi,t=Qi×Pi,tjQj×Pj,tw_{i,t} = \frac{Q_i \times P_{i,t}}{\sum_{j} Q_j \times P_{j,t}}
  • QiQ_i: the index-eligible supply of constituent ii, as defined by that index's series methodology.

  • Pi,tP_{i,t}: the US dollar reference rate for constituent ii at time tt.

Which supply measure fills QiQ_i depends on the series, and the two in use are not interchangeable. The Multi Asset Series weights by adjusted free float market capitalization, which discounts supply that is restricted or effectively unavailable to the market (see the Adjusted Free Float Supply Methodology). The Total Market Series weights by estimated market capitalization instead. Check the methodology document for the series you are using rather than assuming free float.

Weights therefore drift continuously between rebalances as constituent prices move relative to one another. They are recomputed and stored once an hour, every hour, including weekends and holidays, which is the resolution this endpoint publishes.

Equal-weighted indexes follow the same shape with a different starting point: the index is divided evenly across constituents at each rebalance, and weights then drift with relative performance until the next rebalance resets them to equal.

Rebalancing

Which assets are in an index, and the supply figures used to weight them, are set on the index's rebalance schedule. A rebalance takes effect at 16:00 New York time. Constituent selection rules are defined per series in the Methodologies documents and governed by the CMBI Index Policies, with eligible-market rules in the Candidate Market Guidelines.

Because the index divisor is reset at each rebalance to preserve continuity, a rebalance shows up in this data as a change in the constituent set or in the weights, and not as a discontinuity in the index level.

Indexes whose composition does not change

Not every index has a drifting basket. A single-asset index has exactly one constituent at a weight of 1, and the CMBI Mining Series indexes likewise resolve to a single constituent. These indexes have a fixed composition rather than an hourly one, so the endpoint stores a single record at the start of the index's history.

The two cases behave differently on the wire, and the difference matters when you write a query:

  • Changing composition (multi-asset and momentum indexes): stored hourly, and returned exactly as stored. Gaps are never filled, because a gap could be a real change.

  • Fixed composition (single-asset and mining indexes): stored once. If you request a frequency, the last known composition is carried forward so you receive one row per interval across your whole time range. If you omit frequency, you receive only the stored record, at its original timestamp.

Frequency and the default

The frequency parameter selects the sampling of the returned series. If you omit it, you get every stored record rather than a sampled one. How much data that is depends entirely on the index:

  • For an index whose weights drift, such as a multi-asset index, a record is stored every hour, so omitting frequency returns an hourly series. Over a month that is roughly 24 times more rows than frequency=1d.

  • For an index whose composition is fixed, such as a single-asset or mining index, there is only ever one stored record, so omitting frequency returns that single row at its original timestamp.

The API describes this default as returning "only changed constituents", and that is accurate at the storage layer: a record exists because something changed. It is worth being precise about what changed, though. On a market-capitalization index the constituent weights change every hour as prices move, while the constituent set changes only at a rebalance. So the unsampled series is not a rebalance log, and reconstructing rebalance dates means comparing the asset list between consecutive records rather than counting them.

Supported values are 1h, 1d, 1d-ny-close, 1d-ny-midday, and 1d-sg-close. The daily shorthands carry their own time zone, so no separate timezone parameter is needed: 1d-ny-close is 16:00 New York, 1d-ny-midday is 12:00 New York, and 1d-sg-close is 16:00 Singapore. Returned timestamps are always UTC, so a New York close appears as 20:00:00Z during Eastern Daylight Time. Because the underlying data is hourly, sub-hourly frequencies are not offered.

Plain 1d samples at 00:00 UTC, and passing timezone moves that sample to local midnight in the given zone: frequency=1d&timezone=Asia/Tokyo returns one observation per Tokyo day, stamped 15:00:00Z. With frequency=1h, timezone changes nothing about which observations you get, only how your start_time and end_time are read.

Coin Metrics indexes and third-party indexes

Alongside the CMBI series, Coin Metrics distributes constituent data for indexes produced by third-party index providers. These are served through the same endpoint and the same envelope, but their constituent entries are richer: in addition to asset and weight, a provider index typically supplies price, quantity, and weight_basis_value, which together show how the provider arrived at each weight.

Two differences to watch for. First, those three extra fields are absent for CMBI indexes, whose entries carry only asset and weight. Second, the asset value on a provider index is the provider's own symbol rather than a Coin Metrics asset ID, so it may appear as something like BTC-USD instead of btc.

Accessing the Data

Index constituents are available over HTTP at /timeseries/index-constituents. There is no websocket feed, because composition is published hourly at most.

The indexes parameter accepts a comma-separated list or wildcard patterns such as CMBI* or *BTC, so you can query many indexes in one call. This endpoint has no per-index row limit, so bound a query with start_time and end_time rather than by row count. Requesting format=csv flattens each observation into one row per constituent, carrying index, time, asset, and weight.

Full parameter reference: see the API Reference for /timeseries/index-constituents.

Examples

The examples below show constituents for representative indexes. Weights are returned as JSON strings.

Example: hourly weights for a multi-asset index

The latest hourly composition of CMBI10. The ten weights sum to 1. Run this query.

Example: a single-asset index

CMBIBTC holds one constituent at a weight of 1, stored once at the start of its history. Without a frequency, the single stored record is returned at its original timestamp. Run this query.

Adding frequency=1d carries that composition forward, one row per day:

Example: a third-party index with full constituent detail

A provider index also supplies price, quantity, and weight_basis_value for each constituent. Note that asset here is the provider's own symbol rather than a Coin Metrics asset ID. Run this query.

Coverage

Usage

  • Replication. The weights are the instruction set for holding an index. Sampling them at 1d-ny-close gives a reproducible daily target that lines up with a New York close.

  • Exposure decomposition. Multiply index exposure by constituent weights to see the underlying asset exposure, and re-derive it whenever weights drift.

  • Rebalance analysis. Pull the weight history and compare the asset list between consecutive observations. A change in the set of assets marks a rebalance, whereas a change in the weights alone is just price drift.

  • Attribution. Pair a weight history with Reference Rates for the same assets to attribute index return to individual constituents.

  • Transparency and diligence. The composition of every index is published on the same schedule as its levels, so an index level can always be traced back to what produced it.

Limitations

  • Hourly resolution. Weights are stored once an hour. Sub-hourly frequencies are not available, even though the index level itself updates far more often.

  • Omitting frequency is not a smaller query. It returns every stored record, which for a multi-asset index is hourly. Set a frequency when you want a sampled series, and expect roughly 24 times more rows without one.

  • Gaps are not filled for changing baskets. For an index whose composition changes hourly, a missing hour is returned as missing rather than carried forward, because a carried-forward value could hide a real change.

  • Extra constituent fields are provider-specific. price, quantity, and weight_basis_value are populated for third-party indexes and absent for CMBI indexes.

  • No dedicated catalog endpoint. There is no /catalog-v2/index-constituents. Use /catalog-v2/index-levels or /catalog-all-v2/index-levels to discover indexes, then query this endpoint.

FAQ

Do single-asset indexes return constituents?

Yes. A single-asset index returns exactly one constituent at a weight of 1, and so do the CMBI Mining Series indexes. Their composition is fixed rather than hourly, so a single record is stored, and it is carried forward across your time range when you supply a frequency.

Why did my query return only one row for a whole year?

You queried an index whose composition is fixed, such as a single-asset or mining index, without a frequency. Those indexes have exactly one stored record. Add frequency=1d to carry that composition forward and get one row per day.

Why did my query return far more rows than I expected?

You most likely omitted frequency on a multi-asset index. Records are stored hourly, because the weights drift with prices, so an unsampled pull returns roughly 24 times what frequency=1d returns.

Do the weights sum to 1?

Yes, within a single observation, up to rounding in the last digits. They are decimal fractions of the index, not percentages, so multiply by 100 to display them as percentages.

How often do weights change?

Continuously in economic terms, and hourly in published terms. Weights drift with constituent prices between rebalances and are recomputed and stored once an hour. The constituent set itself changes only at a rebalance, which takes effect at 16:00 New York time.

What are price, quantity, and weight_basis_value?

They are the provider-supplied inputs behind a weight on a third-party index: the constituent's price, the number of units held per index unit, and the resulting value that the weight is computed from. They are not returned for CMBI indexes.

Is there a websocket feed for constituents?

No. Composition is published hourly at most, so the HTTP endpoint is the only access path. For a real-time feed, stream Index Levels.

Which indexes have constituent data?

Every index served by this endpoint returns constituents, including single-asset and mining indexes with their single fixed member. Discover the index universe through /catalog-v2/index-levels or the coverage tool.

Last updated