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.
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
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.
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.
{
"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.
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
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
idsurvives them; a cached symbol will not.
Related
- Entity resolution — how a provider payload becomes a canonical asset.
- Asset resolver — look up a symbol or name against the registry.
- Data model — the full canonical schema.