Data / Assets

Asset metadata

The registry every other series hangs off. One canonical identity per asset, with the provider identifiers, category tags and channel pointers needed to join everything else to it.

7,461
assets in the registry
225
symbols used by more than one asset
460
assets affected by those collisions
69
assets with full channel mapping

Why this is the most important page in the data section

Every other category on this site is a time series. A time series is worthless if you cannot say with certainty which asset it belongs to. The registry is what makes that claim possible, and it is the single point where a mistake poisons everything downstream at once.

Symbols are not identities

In the current registry, 225 symbols are shared by 460 distinct assets. Not historical curiosities — live tickers, in the covered set, today. Three separate assets trade as HYPER. Two as ACT. Two as ADS.

Any system that keys on a ticker will, sooner or later, attach the wrong price to the wrong project. That is not a rare edge case in this asset class; it is the normal condition. The registry exists so that nothing internal ever joins on a symbol.

The canonical record

Core identity

idintegerThe canonical Moonlytics asset identifier. Stable for the lifetime of the asset. This is the only field anything internal joins on.
symbolstringTicker as published. Not unique — see below.
namestringDisplay name as published.
createdAttimestampWhen the asset first entered the registry.
updatedAttimestampWhen its record last changed.

Cross-provider mapping

The same asset carries a different identifier at every provider. The registry holds all of them against one canonical id, which is what allows an hourly market row and a daily repository row to be recognised as describing the same thing.

marketProviderIdidentifierThe asset identifier used by the market and social aggregator. Joins the hourly observation series.
metadataProviderIdslugThe slug used by the metadata provider — for example "bitcoin", "avalanche-2", "the-open-network". Joins the daily metadata and ecosystem series.
categoriesstring[]Sector tags as published by the metadata provider. Assets routinely carry several.
imageurlLogo reference from the metadata provider.

Channel pointers

Where the project's public presence lives. These are the join keys for the ecosystem and developer series, and the fields most likely to be wrong on arrival — hence the explicit override flags.

twitter_screen_namestringThe project's primary X handle. Joins the daily channel series.
subreddit_urlurlThe project's primary community source.
github_urlstringSemicolon-separated list of the project's primary repositories.
override_twitter_screen_namebooleanTrue when the handle was corrected by hand because the provider value was wrong.
override_subreddit_urlbooleanTrue when the community pointer was corrected by hand.
override_github_urlbooleanTrue when the repository list was corrected by hand.
canonical asset record
{
  "id": 1,
  "symbol": "BTC",
  "name": "Bitcoin",
  "metadataProviderId": "bitcoin",
  "categories": ["Layer 1", "Proof of Work"],
  "channels": {
    "twitter_screen_name": "bitcoin",
    "subreddit_url": "https://www.reddit.com/r/Bitcoin/",
    "github_url": "https://github.com/bitcoin/bitcoin;https://github.com/bitcoin/bips",
    "override_github_url": true
  },
  "createdAt": "2024-12-25T19: 03: 32.756Z",
  "updatedAt": "2026-08-30T11: 01: 04.377Z"
}

Networks and contract addresses

The full identity of a token includes the network it lives on and its contract address; a name and a ticker do not distinguish a token from a bridged wrapper of itself, or from an unrelated deployment using the same name on a different chain.

Current state

Network and contract-address fields are not yet part of the canonical record. The registry today resolves identity through provider identifiers, not through on-chain addresses. Contract-level identity is on the roadmap and will be documented here when it exists — we would rather say that plainly than describe a field you cannot use.

How assets enter the registry

Provider payload
provider idsymbolname
Lookup
find by provider idnever by symbol
Create or attach
unseen → new canonical assetknown → attach observation
Enrich
metadata provider recordcategorieschannel pointers
Registry
7,461 assetsstable idsappend only

Assets are never removed. An asset that stops appearing in the covered set keeps its identifier and its history, so a series that resumes months later resumes on the same record rather than forking into a second one.

Limitations

  • No contract-level identity yet. Network and address fields are planned, not present.
  • Registry breadth exceeds series breadth. 7,461 assets have an identity; 7,218 have observations, and only 69 have full channel mapping. Presence in the registry is not a promise of data.
  • Categories are inherited. Sector tags come from the metadata provider. They are inconsistent across the long tail and are not a taxonomy we maintain.
  • Names and symbols change. Rebrands happen and are applied in place. The canonical id survives them; a cached symbol will not.

Related