> For the complete documentation index, see [llms.txt](https://gitbook-docs.coinmetrics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook-docs.coinmetrics.io/reference-data/profiles-overview/asset-profiles.md).

# 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

<table data-full-width="true"><thead><tr><th>Data type</th><th>Entities</th><th width="159">Frequency / cadence</th><th>Unit</th><th>Primary endpoint</th><th>Coverage</th></tr></thead><tbody><tr><td>Asset descriptions (reference data)</td><td>Assets</td><td>Reference data, published in releases as profiles are added or revised</td><td>Descriptive text, categorical labels, and dates</td><td><code>/profile/assets</code></td><td><a href="https://docs.coinmetrics.io/api/v4/#operation/getAssetProfiles">🔗</a></td></tr></tbody></table>

## 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](#curation-depth) for why, and [How absent values are represented](#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

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>asset</code></td><td>string</td><td>Coin Metrics name of the asset, lowercased. Joins directly to the rest of the API.</td><td>Required</td></tr><tr><td><code>full_name</code></td><td>string</td><td>Full name of the asset.</td><td>Required</td></tr><tr><td><code>description</code></td><td>string</td><td>One or two sentences describing the asset's key features.</td><td>Required</td></tr><tr><td><code>overview</code></td><td>string</td><td>Longer description of the asset's key features and of the problem it was created to solve.</td><td>Required</td></tr><tr><td><code>creation_date</code></td><td>string (date)</td><td>Date of the asset's genesis block or first included block.</td><td>Required. Served as <code>YYYY-MM-DD</code></td></tr><tr><td><code>website</code></td><td>string</td><td>Official project website. Absent when no official website was found.</td><td>Optional. All profiles</td></tr><tr><td><code>whitepaper_url</code></td><td>string</td><td>Official whitepaper. Absent when no official whitepaper was found.</td><td>Optional. All profiles</td></tr><tr><td><code>blog_updates</code></td><td>string</td><td>Blog on which the project posts updates.</td><td>Optional. Extended</td></tr><tr><td><code>project_github_repository</code></td><td>array[string]</td><td>Repositories relevant to the project.</td><td>Optional. Extended</td></tr></tbody></table>

### Project and purpose

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>token_purpose</code></td><td>array[string]</td><td>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.</td><td>Optional. Extended</td></tr><tr><td><code>project_team</code></td><td>string</td><td>Name of the project team supporting the asset.</td><td>Optional. Extended</td></tr><tr><td><code>foundation</code></td><td>string</td><td>Name of the foundation supporting the asset.</td><td>Optional. Extended</td></tr></tbody></table>

### Supply, issuance, and distribution

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>token_generation_event_supply</code></td><td>string</td><td>Total supply of the token minted at genesis.</td><td>Optional. Extended</td></tr><tr><td><code>supply_cap</code></td><td>string</td><td>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 <a href="#reading-the-supply-cap">Reading the supply cap</a>.</td><td>Optional. All profiles</td></tr><tr><td><code>initial_supply_token_distribution</code></td><td>array[object]</td><td>Initial allocation of tokens, as a list of receiving entities and the share each received. Sub-fields: <code>initial_supply_allocation</code> (string, the receiving entity), <code>initial_supply_distribution</code> (string, the amount or percentage received).</td><td>Optional. Extended</td></tr><tr><td><code>vesting_schedule</code></td><td>array[object]</td><td>Vesting schedules disclosed by the project. Sub-fields: <code>vesting_schedule_allocation</code> (string, the entity subject to the schedule), <code>vesting_schedule_cliff</code> (string, the cliff in years), <code>vesting_schedule_total_unlock_time</code> (string, the total unlock period in years).</td><td>Optional. Extended</td></tr><tr><td><code>new_token_issuance_recipient</code></td><td>array[string]</td><td>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.</td><td>Optional. Extended</td></tr><tr><td><code>issuance_schedule_changes</code></td><td>string</td><td>Changes that have occurred to the asset's issuance schedule, including the halving cadence where one applies.</td><td>Optional. Extended</td></tr></tbody></table>

### Networks

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>issuing_networks</code></td><td>array[string]</td><td>Networks on which the asset is natively issued, meaning not bridged or wrapped.</td><td>Optional. Extended</td></tr><tr><td><code>bridged_networks</code></td><td>array[string]</td><td>Networks the asset has been bridged to, including bridging by wrapping. Bitcoin, for example, is bridged to Ethereum by wrapping as WBTC.</td><td>Optional. Extended</td></tr></tbody></table>

Both fields carry network display names rather than the network identifiers used by [Network Profiles](/reference-data/profiles-overview/network-profiles.md). See [Network names are not network identifiers](#network-names-are-not-network-identifiers).

### History

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>significant_historical_changes</code></td><td>array[object]</td><td>Notable events in the history of the asset or project. Sub-fields: <code>date</code> (string), <code>details</code> (string).</td><td>Optional. Extended</td></tr><tr><td><code>upgrade_history</code></td><td>array[object]</td><td>Upgrades made to the asset or project. Sub-fields: <code>date</code> (string), <code>details</code> (string).</td><td>Optional. Extended</td></tr></tbody></table>

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](#event-dates-are-free-text).

### Regulation

<table data-full-width="true"><thead><tr><th width="230">Field</th><th width="130">Type</th><th>Description</th><th width="150">Notes</th></tr></thead><tbody><tr><td><code>asset_regulation</code></td><td>string</td><td>How the asset is regulated, as <code>Directly</code> or <code>Indirectly</code>. 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.</td><td>Optional. Extended</td></tr><tr><td><code>asset_regulated_products</code></td><td>array[string]</td><td>Regulated products released for the asset, such as exchange-traded products and exchange-traded funds.</td><td>Optional. Extended</td></tr><tr><td><code>etp_custodians</code></td><td>array[string]</td><td>Known custodians of the underlying asset for exchange-traded products.</td><td>Optional. Extended</td></tr></tbody></table>

{% hint style="info" %}
**Conventions.** All values are returned as JSON strings, including numeric ones such as `supply_cap`, so that large supply figures keep full precision. Asset names are lowercased Coin Metrics asset names, so `dai` rather than `DAI`. `creation_date` is served as a plain calendar date with no time of day and no zone offset. There are no per-observation timestamps on this endpoint, because a profile describes an asset as it stands rather than at a point in time. A field that cannot be commented on, or that has not yet been researched for an asset, is omitted from the object rather than returned as null. A field that has been researched and found not applicable is returned as the string `N/A` (see [How absent values are represented](#how-absent-values-are-represented)).
{% endhint %}

## 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](#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](#example-an-extended-asset-profile) 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:

```python
cap = profile.get("supply_cap")
capped = cap is not None and cap.isdigit()
```

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](/reference-data/profiles-overview/network-profiles.md), 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.

* [`/profile/assets`](https://docs.coinmetrics.io/api/v4/#operation/getAssetProfiles)

{% hint style="warning" %}
**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.
{% endhint %}

{% tabs %}
{% tab title="Python Client" %}

```python
import os
import pandas as pd
from coinmetrics.api_client import CoinMetricsClient

client = CoinMetricsClient(os.environ["CM_API_KEY"])

# Profiles for specific assets
profiles = client.get_asset_profiles(assets=["btc", "eth", "dai"]).to_list()
print(pd.DataFrame(profiles))

# Look up by full name instead of asset name
bitcoin = client.get_asset_profiles(full_names=["Bitcoin"]).to_list()

# The whole covered universe, paginated automatically by the client
universe = client.get_asset_profiles().to_list()
```

{% endtab %}

{% tab title="Shell" %}

```shell
curl --compressed "https://api.coinmetrics.io/v4/profile/assets?assets=btc,eth,dai&page_size=10000&api_key=$CM_API_KEY"
```

{% endtab %}

{% tab title="Python" %}

```python
import os
import requests

response = requests.get(
    "https://api.coinmetrics.io/v4/profile/assets",
    params={
        "assets": "btc,eth,dai",
        "page_size": 10000,
        "api_key": os.environ["CM_API_KEY"],
    },
).json()
```

{% endtab %}
{% endtabs %}

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`](https://docs.coinmetrics.io/api/v4/#operation/getAssetProfiles).

## Examples

The two examples below are live responses showing each level of [curation depth](#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](https://api.coinmetrics.io/v4/profile/assets?assets=dai\&api_key=YOUR_API_KEY).

```json
{
  "data": [
    {
      "asset": "dai",
      "full_name": "Dai",
      "description": "Dai is a decentralized crypto-backed stablecoin on Ethereum Network created by MakerDAO.",
      "overview": "Dai is a decentralized crypto-backed stablecoin on Ethereum Network created by MakerDAO. It is soft-pegged to the USD and is collateralized by a mix of cryptocurrencies that are deposited into smart-contract vaults every time a new Dai is minted. Users who deposit assets to mint Dai tokens can then earn Dai by locking it in the Dai Savings Rate (DSR) smart contract. The rate of return is set through the MKR token holders using on-chain governance. Dai is meant to be fully accessible to any individual or business.",
      "creation_date": "2017-12-18",
      "token_purpose": [
        "Stablecoin",
        "Deposit Receipt"
      ],
      "project_team": "MakerDAO",
      "foundation": "N/A",
      "website": "https://makerdao.com/en/",
      "whitepaper_url": "https://makerdao.com/whitepaper/DaiDec17WP.pdf",
      "token_generation_event_supply": "N/A",
      "supply_cap": "N/A",
      "initial_supply_token_distribution": [
        {
          "initial_supply_allocation": "N/A",
          "initial_supply_distribution": "N/A"
        }
      ],
      "vesting_schedule": [
        {
          "vesting_schedule_allocation": "N/A",
          "vesting_schedule_cliff": "N/A",
          "vesting_schedule_total_unlock_time": "N/A"
        }
      ],
      "new_token_issuance_recipient": [
        "Minter"
      ],
      "issuing_networks": [
        "Ethereum",
        "Base",
        "Gnosis"
      ],
      "bridged_networks": [
        "OP Mainnet",
        "Arbitrum",
        "Polygon PoS",
        "Avalanche C-Chain",
        "BSC"
      ],
      "issuance_schedule_changes": "N/A",
      "upgrade_history": [
        {
          "date": "2024-08-27",
          "details": "Sky Ecosystem announced the release of USDS stablecoin which can be converted to from DAI"
        }
      ],
      "blog_updates": "https://blog.makerdao.com/",
      "project_github_repository": [
        "https://github.com/makerdao"
      ],
      "asset_regulation": "N/A",
      "asset_regulated_products": [
        "N/A"
      ],
      "etp_custodians": [
        "N/A"
      ]
    }
  ]
}
```

### 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](https://api.coinmetrics.io/v4/profile/assets?assets=algo\&api_key=YOUR_API_KEY).

```json
{
  "data": [
    {
      "asset": "algo",
      "full_name": "Algorand",
      "description": "Algorand is a smart contract, Pure Proof-of-Stake (PPoS) blockchain protocol.",
      "overview": "Algorand is a smart contract, Pure Proof-of-Stake (PPoS) blockchain protocol. Algorand relies on a binary Byzantine agreement consensus mechanism to reach an agreement on new blocks added to the chain. The blockchain utilizes a two-thirds Byzantine Fault Tolerance, meaning the network will stay operational if less than one-third of nodes are behaving honestly. ALGO is the native governance token of the Algorand blockchain. Network participants that stake ALGO is randomly selected, proportionate to their stake, to propose new blocks and to vote on block proposals, and earn ALGO as compensation for staking. Users also need ALGO to pay transaction fees on the network. ",
      "creation_date": "2019-06-11",
      "website": "https://www.algorand.com/",
      "whitepaper_url": "https://arxiv.org/pdf/1607.01341.pdf",
      "supply_cap": "10000000000"
    }
  ]
}
```

## 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`](https://docs.coinmetrics.io/api/v4/#operation/getAssetProfiles): 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.

{% tabs %}
{% tab title="Python Client" %}

```python
import os
from coinmetrics.api_client import CoinMetricsClient

client = CoinMetricsClient(os.environ["CM_API_KEY"])

profiles = client.get_asset_profiles().to_list()

# Every asset with a profile
covered = sorted(p["asset"] for p in profiles)

# Split the universe by curation depth
extended = sorted(p["asset"] for p in profiles if "project_team" in p)
core_only = sorted(set(covered) - set(extended))
```

{% endtab %}

{% tab title="Shell" %}

```shell
curl --compressed "https://api.coinmetrics.io/v4/profile/assets?page_size=10000&api_key=$CM_API_KEY"
```

{% endtab %}
{% endtabs %}

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`](https://docs.coinmetrics.io/api/v4/#operation/getReferenceDataAssets).

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 `asset` field 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`, and `asset_regulated_products` support 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_networks` and `bridged_networks` separate 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`, and `vesting_schedule` together 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_changes` and `upgrade_history` give 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](#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/A` is 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](#how-absent-values-are-represented)).
* **`supply_cap` expresses 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](#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_regulation` records 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.** `date` inside `significant_historical_changes` and `upgrade_history` is not a fixed format and cannot be parsed reliably (see [Event dates are free text](#event-dates-are-free-text)).
* **`.to_dataframe()` fails on this endpoint.** The Python client cannot parse `creation_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](#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](#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-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](/reference-data/profiles-overview.md) 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](#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](#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](#event-dates-are-free-text).

## Related

* [Profiles Overview](/reference-data/profiles-overview.md): how asset and network profiles fit together, plus the release change log.
* [Network Profiles](/reference-data/profiles-overview/network-profiles.md): the same descriptive treatment for the networks assets are issued on and bridged to.
* [Asset Taxonomy](/reference-data/datonomy-overview/asset-taxonomy.md): the datonomy classification of the same assets, as codes and names rather than prose.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://gitbook-docs.coinmetrics.io/reference-data/profiles-overview/asset-profiles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.