Asset Profiles
Overview
An asset profile is a structured, human-curated description of a cryptoasset. It answers the questions that a price series or a market record does not: why the asset exists, who builds it, how its supply was created and how it is distributed, which networks it lives on, what has happened to it since launch, and whether it is regulated or wrapped in a regulated product. Every field is written and reviewed by analysts from primary sources rather than derived from market activity, so a profile reads as an editorial reference rather than a computed dataset.
Research teams use profiles to understand an unfamiliar asset without leaving the API, and to attach durable descriptive context to quantitative work. Product and compliance teams use the supply, issuance, and regulation fields to answer diligence questions consistently across a universe of assets.
At a Glance
Asset descriptions (reference data)
Assets
Reference data, published in releases as profiles are added or revised
Descriptive text, categorical labels, and dates
/profile/assets
Schema
The response returns one object per asset. Only the five required fields appear on every profile. Every other field appears only when it has been researched and found applicable for that asset, which means the set of keys differs from one profile to the next. See Curation depth for why, and How absent values are represented for how to read a field that is present but carries no information.
Fields are grouped below by what they describe. Every field returned by the endpoint appears exactly once across these tables.
Identity and description
asset
string
Coin Metrics name of the asset, lowercased. Joins directly to the rest of the API.
Required
full_name
string
Full name of the asset.
Required
description
string
One or two sentences describing the asset's key features.
Required
overview
string
Longer description of the asset's key features and of the problem it was created to solve.
Required
creation_date
string (date)
Date of the asset's genesis block or first included block.
Required. Served as YYYY-MM-DD
website
string
Official project website. Absent when no official website was found.
Optional. All profiles
whitepaper_url
string
Official whitepaper. Absent when no official whitepaper was found.
Optional. All profiles
blog_updates
string
Blog on which the project posts updates.
Optional. Extended
project_github_repository
array[string]
Repositories relevant to the project.
Optional. Extended
Project and purpose
token_purpose
array[string]
The main purposes the asset serves, for example a fee token on a network, a stablecoin, or a governance token. Observed values are Governance Token, Staking Token, Deposit Receipt, Fee Token, Stablecoin, Native Collateral Token, and Store of Value Token.
Optional. Extended
project_team
string
Name of the project team supporting the asset.
Optional. Extended
foundation
string
Name of the foundation supporting the asset.
Optional. Extended
Supply, issuance, and distribution
token_generation_event_supply
string
Total supply of the token minted at genesis.
Optional. Extended
supply_cap
string
Maximum number of units programmed to exist over the lifetime of the asset. Uncapped supply is expressed two different ways, so test for a numeric value rather than for the key's presence. See Reading the supply cap.
Optional. All profiles
initial_supply_token_distribution
array[object]
Initial allocation of tokens, as a list of receiving entities and the share each received. Sub-fields: initial_supply_allocation (string, the receiving entity), initial_supply_distribution (string, the amount or percentage received).
Optional. Extended
vesting_schedule
array[object]
Vesting schedules disclosed by the project. Sub-fields: vesting_schedule_allocation (string, the entity subject to the schedule), vesting_schedule_cliff (string, the cliff in years), vesting_schedule_total_unlock_time (string, the total unlock period in years).
Optional. Extended
new_token_issuance_recipient
array[string]
Who receives newly issued tokens. Where tokens go to a class of participant rather than a named entity, the class is listed, for example Miner, Validator, Staker, or Minter.
Optional. Extended
issuance_schedule_changes
string
Changes that have occurred to the asset's issuance schedule, including the halving cadence where one applies.
Optional. Extended
Networks
issuing_networks
array[string]
Networks on which the asset is natively issued, meaning not bridged or wrapped.
Optional. Extended
bridged_networks
array[string]
Networks the asset has been bridged to, including bridging by wrapping. Bitcoin, for example, is bridged to Ethereum by wrapping as WBTC.
Optional. Extended
Both fields carry network display names rather than the network identifiers used by Network Profiles. See Network names are not network identifiers.
History
significant_historical_changes
array[object]
Notable events in the history of the asset or project. Sub-fields: date (string), details (string).
Optional. Extended
upgrade_history
array[object]
Upgrades made to the asset or project. Sub-fields: date (string), details (string).
Optional. Extended
The date sub-field on both is recorded at the most granular format that can be accurately asserted, so its precision varies by entry. See Event dates are free text.
Regulation
asset_regulation
string
How the asset is regulated, as Directly or Indirectly. Direct regulation means explicit regulatory guidance applies to the asset itself, for example under MiCA in the European Union. Indirect regulation means the asset is reached through a regulated product such as a spot exchange-traded fund.
Optional. Extended
asset_regulated_products
array[string]
Regulated products released for the asset, such as exchange-traded products and exchange-traded funds.
Optional. Extended
etp_custodians
array[string]
Known custodians of the underlying asset for exchange-traded products.
Optional. Extended
Methodology
Asset profiles are written rather than computed. Analysts research each asset from primary sources, record the result in a structured dataset, and publish it through the API.
Sourcing and curation
Every field traces to a primary source. Project websites, whitepapers, official documentation, governance forums, public repositories, and regulatory filings are the usual ones. Where a project's own material is ambiguous or silent, the field is left uncurated rather than inferred, which is why the depth of a profile reflects how much a project has actually disclosed.
Curated content is held in a version-controlled dataset and validated against a published schema before it can be released. The schema fixes the field names, types, and nesting, so a release cannot introduce a malformed profile or silently rename a field. Editorial review sits ahead of that validation, so a change is reviewed before it is merged.
Release cadence
Profiles are published in discrete releases rather than updated continuously. The API serves a pinned version of the profile dataset, and a release replaces that pinned version wholesale. Between releases the response is stable. There is no fixed schedule and the interval between releases is not fixed.
Because releases are discrete, a newly launched asset does not appear the moment it starts trading, and a change in a project's circumstances is reflected at the next release rather than immediately.
Curation depth
Profiles come at two depths, and the difference is substantial enough to plan around.
Every profile carries the core fields: asset, full_name, description, overview, creation_date, and, where they exist, website, whitepaper_url, and supply_cap. This is the descriptive baseline, and it is available for the whole covered universe.
A smaller set of assets also carries the extended fields, meaning everything else in the schema: purpose and team, supply and vesting detail, issuing and bridged networks, event history, and regulatory status. These are the assets that have been through the deeper curation process, which is ongoing and expands with each release.
How absent values are represented
A field can be missing information in two distinct ways, and they mean different things.
An omitted key means the field either cannot be commented on for that asset or has not yet been researched. Nothing has been asserted about it either way. Most omissions are simply an asset that has not yet had the extended fields written. supply_cap is the one exception, where an omitted key is itself the answer (see Reading the supply cap).
The string N/A means the field has been researched and analysts have concluded it is not applicable to that asset: it has no supply cap, no vesting schedule, no foundation, or no regulated products. This is a positive statement of absence rather than a gap.
Neither state is permanent. Both are revisited as research continues, so a field that is absent or N/A today can carry a value in a later release.
N/A appears wherever a string is expected, including inside arrays and inside the objects nested in vesting_schedule, initial_supply_token_distribution, significant_historical_changes, and upgrade_history. An array whose only element is an N/A object is the empty case for that field, not a real entry, so code that counts vesting tranches or historical events should filter it out before counting. The Dai example shows this shape.
Because N/A is a string, it also appears in fields that otherwise hold numbers. supply_cap is "N/A" for many assets with no cap, so parse it defensively rather than casting straight to a number.
Reading the supply cap
supply_cap is the one field where an omitted key carries meaning, so the general rule above does not apply to it. The field has three states, and two of them mean the same thing:
A numeric string, such as
"21000000". The asset has a programmed maximum supply.The string
"N/A". The asset is uncapped. This is the researched answer, meaning analysts looked and concluded there is no cap.The key absent. Also uncapped. Assets with no programmed maximum are the reason the field is optional in the first place.
Both "N/A" and absence are used for uncapped assets, which is why a presence check is the wrong test. usdc and dai report "N/A", while eos, near, and xtz omit the key, and all of them are uncapped. Read the field by testing whether the value parses as a number, and treat everything else as uncapped:
One caveat. On a core profile, where most fields are uncurated anyway, an absent supply_cap is weaker evidence than it is on an extended profile, because you cannot tell a researched "uncapped" from a field that has not been researched yet. If the distinction matters for your use case, restrict the test to extended profiles.
Event dates are free text
The date sub-field inside significant_historical_changes and upgrade_history is recorded at the most granular format that can be accurately asserted, up to a full calendar date. Where the exact date can no longer be ascertained, it falls back to the month, or to the year, depending on which granularity holds up. Values therefore range from a full date such as 2024-08-27, to a month such as 2012-04, to a year such as 2014, to N/A where the timing is unknown.
Because the granularity varies from one entry to the next, parse the field as text and treat any date arithmetic on it as best effort. A coarser value is a statement about how precisely the event can be dated, not a placeholder for a date that exists somewhere else. The same applies to the date sub-field on network profiles.
Network names are not network identifiers
issuing_networks and bridged_networks carry human-readable network names such as Ethereum, OP Mainnet, and Avalanche C-Chain. These are display names written for a reader, not keys. They do not match the network identifiers used by Network Profiles, where the same networks are eth, op, and avaxc, and the profile universe covers many networks that have no network profile of their own. Join on these fields by name matching with care, and do not assume a name resolves to a network profile.
Accessing the Data
Asset profiles are served on a single endpoint, filtered by asset name or by full name.
Use .to_list() on this endpoint, not .to_dataframe(). creation_date is returned as a calendar date with no zone offset, which the Python client's dataframe conversion cannot parse, so .to_dataframe() raises on every asset profile request. Build the frame with pd.DataFrame(...) from the list instead, as shown below. Network profiles are unaffected, because they carry no date field.
Responses are paginated. The Python client follows pagination automatically, while direct HTTP callers page through results using next_page_token. The default page size is 100, so an unfiltered request that does not raise page_size or follow next_page_url returns only the first page. This endpoint does not support the format parameter, so json is the only representation and there is no CSV or streaming variant. Full parameter reference: see the API Reference for /profile/assets.
Examples
The two examples below are live responses showing each level of curation depth. Both are complete, with nothing truncated.
Example: an extended asset profile
A fully curated profile, carrying the whole schema. Note the N/A entries: Dai has no foundation, no supply cap, and no regulated products, and the single-element initial_supply_token_distribution and vesting_schedule arrays are the empty case rather than real allocations. Run this query.
Example: a core asset profile
The same endpoint for an asset that has not yet been through extended curation. The response is complete: the extended keys are omitted rather than returned empty, so an integration that assumes a fixed set of keys will break on profiles of this shape. Run this query.
Coverage
Asset profiles are not published on coverage.coinmetrics.io, and unlike the metric datasets they have no catalog endpoint either. Availability is read from the profile endpoint itself instead, which returns every asset that has a profile. This is the authoritative list of what is covered, and it stays current across releases.
/profile/assets: queried with no filters, returns every covered asset. There is no separate complete-versus-entitled view, because the endpoint returns what the requesting key is entitled to see.
The profile universe is a subset of the assets Coin Metrics covers elsewhere, so an asset with market or network data does not necessarily have a profile. It also runs the other way, because an asset name that appears in a profile is a standard Coin Metrics asset name and joins to the rest of the API. To check both sides, compare this list against /reference-data/assets.
Access to profiles is entitled separately from other datasets, so a key without the entitlement receives an authorization error rather than an empty result.
Usage
Enrich a quantitative universe with context. The
assetfield is a standard Coin Metrics asset name, so profiles join directly to/timeseries/asset-metrics,/reference-data/markets, and asset taxonomy classifications. Pulling the whole universe once and caching it is the normal pattern, because the data changes only at a release.Screen by purpose or regulatory status.
token_purpose,asset_regulation, andasset_regulated_productssupport questions such as which covered assets are stablecoins, or which have a spot exchange-traded fund and who custodies the underlying.Map an asset's footprint across chains.
issuing_networksandbridged_networksseparate native issuance from wrapped or bridged representations, which matters when attributing supply or activity to a chain.Answer supply and unlock questions.
token_generation_event_supply,supply_cap,initial_supply_token_distribution, andvesting_scheduletogether describe how a token's supply was created and when it becomes liquid, for the assets where the project has disclosed it.Build an event timeline.
significant_historical_changesandupgrade_historygive dated context for explaining a break in a price or network series, such as a fork, a halving, or a protocol upgrade.Cache and diff between releases. Because the served dataset is pinned between releases, diffing a stored copy against a fresh pull is a reliable way to see exactly what a release changed.
Limitations
The endpoint is marked experimental. It is published as experimental in the API Reference, which means the schema can change with less notice than a stable endpoint. Code defensively against added or renamed fields.
Coverage is a subset of the asset universe. Many assets with market and network data have no profile at all, and the profile universe is not a coverage statement about anything else.
Most profiles carry core fields only. The extended fields exist for a minority of covered assets, so any screen built on
token_purpose,asset_regulation, or the supply fields runs over that subset rather than the whole universe (see Curation depth).The key set varies between profiles. Fields that cannot be commented on or have not been researched are omitted rather than returned as null, so an integration that assumes a fixed schema per row will break. Treat every field except the five required ones as optional.
N/Ais a value, not an absence. It appears in string fields, in arrays, and inside nested objects, including fields that otherwise hold numbers (see How absent values are represented).supply_capexpresses uncapped supply two ways. Some uncapped assets report"N/A"and others omit the key, so a presence check misclassifies one group or the other (see Reading the supply cap).Content is editorial and updates on a release cadence. A profile reflects the state of research at the last release rather than the present moment, so recent events, listings, and regulatory developments can be absent. Nothing here is a real-time feed.
Not investment advice or a regulatory determination.
asset_regulationrecords a researched observation about how an asset is treated, not a legal opinion, and it is not a statement about any particular jurisdiction.Event dates are free text.
dateinsidesignificant_historical_changesandupgrade_historyis not a fixed format and cannot be parsed reliably (see Event dates are free text)..to_dataframe()fails on this endpoint. The Python client cannot parsecreation_date, so the dataframe helper raises. Use.to_list().Network names do not join to network profiles. The network fields carry display names rather than network identifiers (see Network names are not network identifiers).
FAQ
Why does one profile have far more fields than another?
Because profiles come at two levels of curation depth. Every asset gets the core descriptive fields, while the extended fields are written for a smaller set of assets and added to with each release. The depth is not flagged in the response, so detect it from the presence of a key such as project_team. See Curation depth.
What is the difference between an omitted field and "N/A"?
An omitted field is one that either cannot be commented on or has not yet been researched, so nothing has been asserted about it. "N/A" means the field has been researched and analysts concluded it is not applicable to that asset, for example an asset with no supply cap or no vesting schedule. Neither is permanent, and both can be amended in a later release. See How absent values are represented.
How often do profiles change?
Only at a release, and releases have no fixed schedule. Between releases the response is stable, so polling gains nothing. The change log on the Profiles Overview records what each release added or revised.
Why did an asset I requested not come back?
Either it has no profile, or the identifier does not match. Unknown identifiers are dropped silently rather than raising an error, so a request for several assets can return fewer objects than you asked for. Check the returned asset values against your request, and query with no filters to see the covered list.
Can I search profiles by keyword, or filter by a field such as token_purpose?
No. The endpoint filters only on exact assets or full_names identifiers, with no wildcards and no partial matching. To screen on any other field, pull the universe and filter client-side.
Is supply_cap always a number?
No. It is a JSON string, and uncapped assets are represented two different ways: some report the string "N/A" and others omit the key entirely. Test whether the value parses as a number rather than testing for the key's presence, and never cast it directly. See Reading the supply cap.
Do issuing_networks values match the identifiers in Network Profiles?
No. They are display names such as Avalanche C-Chain, while network profiles use identifiers such as avaxc. There is also no requirement that a named network has a profile of its own. See Network names are not network identifiers.
Can I parse the dates in upgrade_history and significant_historical_changes?
Not reliably. Those date sub-fields are free text carrying whatever precision the event is known to, so a full date, a month, a year, and N/A all occur. See Event dates are free text.
Related
Profiles Overview: how asset and network profiles fit together, plus the release change log.
Network Profiles: the same descriptive treatment for the networks assets are issued on and bridged to.
Asset Taxonomy: the datonomy classification of the same assets, as codes and names rather than prose.
Last updated