> 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/network-profiles.md).

# Network Profiles

## Overview

A network profile is a structured, human-curated description of a blockchain network. It answers what the network is designed to do, how it reaches consensus and how quickly transactions become final, who builds and maintains it, what software runs it, and how it has changed over time. Where [Asset Profiles](/reference-data/profiles-overview/asset-profiles.md) describe a token, network profiles describe the settlement layer the token lives on, which is a separate question: many assets are issued on a network they did not create, and several major networks have no single asset of their own.

Research and risk teams use profiles to compare networks on consistent terms rather than on marketing material, for example grouping by consensus mechanism, separating rollups and sidechains from base layers, or checking client diversity. Every field is written and reviewed by analysts from primary sources rather than measured from chain data.

## 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>Network descriptions (reference data)</td><td>Networks</td><td>Reference data, published in releases as profiles are added or revised</td><td>Descriptive text and categorical labels</td><td><code>/profile/networks</code></td><td><a href="https://docs.coinmetrics.io/api/v4/#operation/getNetworkProfiles">🔗</a></td></tr></tbody></table>

## Schema

The response returns one object per network. Network profiles are curated to a consistent depth, so most fields are present on most profiles. A field that cannot be commented on, or that has not yet been researched for a network, is omitted. 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)).

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>network</code></td><td>string</td><td>Coin Metrics identifier for the network, lowercased. Distinct chains of a multi-chain platform get their own identifier, such as <code>avaxc</code>, <code>avaxp</code>, and <code>avaxx</code>.</td><td>Required</td></tr><tr><td><code>full_name</code></td><td>string</td><td>Full name of the network.</td><td>Required</td></tr><tr><td><code>overview</code></td><td>string</td><td>Description of the network's key features and of the problem it was created to solve.</td><td>All profiles</td></tr><tr><td><code>type_of_network</code></td><td>string</td><td>What kind of system the network is. Observed values are <code>Blockchain</code>, <code>Rollup</code>, <code>Sidechain</code>, and <code>Hashgraph</code>.</td><td>All profiles</td></tr><tr><td><code>chain_explorers</code></td><td>array[string]</td><td>Public block explorers for the network.</td><td>All profiles</td></tr></tbody></table>

### Consensus and execution

<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>consensus_mechanism</code></td><td>string</td><td>The protocols, algorithms, and incentives by which nodes agree on the state of the chain. Variants are qualified after a colon, as in <code>Proof-of-Stake: Delegated</code> or <code>Proof-of-Stake: Proof-of-History</code>. A network without its own consensus mechanism carries <code>N/A</code>.</td><td>All profiles</td></tr><tr><td><code>hashing_algorithm</code></td><td>string</td><td>Algorithm the network uses for its hashing operations.</td><td>Optional</td></tr><tr><td><code>transaction_finality</code></td><td>string</td><td>The threshold after which a transaction is considered final, stated in time or in blocks or slots. Networks with probabilistic finality carry <code>No Fixed Finality Threshold</code>.</td><td>All profiles</td></tr><tr><td><code>smart_contract_deployment</code></td><td>string</td><td>Whether contracts can be deployed permissionlessly or under a permissioned model.</td><td>All profiles</td></tr><tr><td><code>transaction_visibility</code></td><td>string</td><td>Whether transactions are visible on chain or hidden, fully or partially.</td><td>All profiles</td></tr><tr><td><code>native_fee_token</code></td><td>string</td><td>Token in which fees are paid on the network. This is a ticker rather than a Coin Metrics asset name.</td><td>All profiles</td></tr><tr><td><code>available_clients</code></td><td>array[string]</td><td>Node client implementations available for the network.</td><td>Optional</td></tr></tbody></table>

### Architecture and scaling

<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>modular_or_monolithic</code></td><td>string</td><td>Whether the network's architecture separates its core functions across layers or combines them. Observed values are <code>Monolithic</code>, <code>Semi Modular</code>, <code>Modular</code>, and <code>Polylithic</code>.</td><td>Required</td></tr><tr><td><code>network_scaling_solution</code></td><td>string</td><td>Whether the network exists to scale another network. Returned as the string <code>"true"</code> or <code>"false"</code>, not as a JSON boolean.</td><td>All profiles</td></tr><tr><td><code>rollup_info</code></td><td>array[object]</td><td>Rollup characteristics, where the network is one. Sub-fields: <code>rollup_type</code> (string, such as <code>Optimistic</code> or <code>Zero-Knowledge (ZK)</code>), <code>state_validation</code> (string, such as <code>Interactive Fraud Proofs</code> or <code>ZK SNARK + STARK proofs</code>). Networks that are not rollups carry a single <code>N/A</code> entry.</td><td>All profiles</td></tr></tbody></table>

### Stewardship

<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>foundation</code></td><td>array[string]</td><td>Organizations supporting development of the network. Each entry is a name followed by a short description of that organization's role.</td><td>All profiles</td></tr><tr><td><code>founding_team_identity</code></td><td>string</td><td>Whether the identity of the founding team is publicly known, as <code>Known</code> or <code>Unknown</code>.</td><td>All profiles</td></tr><tr><td><code>repository</code></td><td>array[object]</td><td>Repositories relevant to the network. Sub-fields: <code>github_repository</code> (string, the repository name), <code>github_url</code> (string, the URL, served without a scheme).</td><td>All profiles</td></tr></tbody></table>

### 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 network's history. Sub-fields: <code>date</code> (string), <code>details</code> (string).</td><td>Optional</td></tr><tr><td><code>upgrade_history</code></td><td>array[object]</td><td>Upgrades the network has undergone. Sub-fields: <code>date</code> (string), <code>details</code> (string).</td><td>Optional</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](/reference-data/profiles-overview/asset-profiles.md#event-dates-are-free-text).

{% hint style="info" %}
**Conventions.** All values are returned as JSON strings. Network identifiers are lowercased, so `avaxc` rather than `AVAXC`. There are no timestamps on this endpoint, because a profile describes a network 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 a network, 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`. The categorical fields are curated vocabularies rather than fixed enumerations in the API contract, so new values can appear in a release without a schema change.
{% endhint %}

## Methodology

Network profiles are written rather than measured. Analysts research each network 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, usually the network's own documentation, specifications and improvement proposals, client repositories, and foundation publications. Where the network's own material is ambiguous or silent, the field is left uncurated rather than inferred.

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. Asset profiles and network profiles share this workflow, and both are published together.

### 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. Releases go out when a batch of new networks or revisions is ready, and each one is recorded in the change log on the [Profiles Overview](/reference-data/profiles-overview.md).

### What counts as a network

A profile describes a distinct settlement environment rather than a brand. Where a platform runs several chains with different roles, each chain is profiled separately, which is why Avalanche appears as `avaxc`, `avaxp`, and `avaxx`, and Polygon appears as `pol_pos` and `pol_zkevm`. Conversely, a network is profiled on its own terms whether or not it has a native asset, so rollups whose fee token is `ETH` are covered in their own right.

The `type_of_network` and `network_scaling_solution` fields carry this structure. A rollup or sidechain that exists to scale another network is marked `"true"` for `network_scaling_solution`, and `rollup_info` carries the rollup's proof system where one applies. Base layers carry `"false"` and an `N/A` rollup entry.

### 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 network or has not yet been researched. Nothing has been asserted about it either way. On network profiles this is uncommon and concentrated in `hashing_algorithm`, `available_clients`, `significant_historical_changes`, and `upgrade_history`.

The **string `N/A`** means the field has been researched and analysts have concluded it is not applicable to that network, for example a network with no hashing algorithm of its own or no rollup characteristics. 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` also appears inside the objects nested in `rollup_info`, `significant_historical_changes`, and `upgrade_history`. An array whose only element is an `N/A` object is the empty case for that field rather than a real entry, so code that reads a rollup's proof system or counts historical events should filter it out first. The [Solana example](#example-a-base-layer-network) shows this shape.

### Networks are not assets

`network` identifiers and Coin Metrics asset names are separate namespaces that overlap without being interchangeable. Some identifiers coincide, so `btc` is both an asset and a network. Others do not: the network `pol_pos` has no asset of that name, and its `native_fee_token` is `matic`. Rollups such as `base`, `arb`, and `op` pay fees in `eth` and have no fee token of their own at all. `native_fee_token` is a display ticker rather than a Coin Metrics asset name.

## Accessing the Data

Network profiles are served on a single endpoint, filtered by network identifier or by full name.

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

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

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

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

# Profiles for specific networks
df = client.get_network_profiles(networks=["btc", "eth", "base"]).to_dataframe()
print(df)

# Look up by full name instead of network identifier
ethereum = client.get_network_profiles(full_names=["Ethereum"]).to_list()

# Every covered network
universe = client.get_network_profiles().to_list()
```

{% endtab %}

{% tab title="Shell" %}

```shell
curl --compressed "https://api.coinmetrics.io/v4/profile/networks?networks=btc,eth,base&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/networks",
    params={
        "networks": "btc,eth,base",
        "page_size": 10000,
        "api_key": os.environ["CM_API_KEY"],
    },
).json()
```

{% endtab %}
{% endtabs %}

Unlike [Asset Profiles](/reference-data/profiles-overview/asset-profiles.md), `.to_dataframe()` works on this endpoint, because network profiles carry no date-typed field for the client to parse.

Responses are paginated. The Python client follows pagination automatically, while direct HTTP callers page through results using `next_page_token`. 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/networks`](https://docs.coinmetrics.io/api/v4/#operation/getNetworkProfiles).

## Examples

The two examples below are live responses, complete and untruncated. They are chosen to contrast a base layer with a rollup, which is where most of the categorical fields differ.

### Example: a base-layer network

A monolithic layer-1 with its own consensus mechanism and fee token. `network_scaling_solution` is `"false"` and `rollup_info` carries the single `N/A` entry that marks the empty case. [Run this query](https://api.coinmetrics.io/v4/profile/networks?networks=sol\&api_key=YOUR_API_KEY).

```json
{
  "data": [
    {
      "full_name": "Solana",
      "network": "sol",
      "modular_or_monolithic": "Monolithic",
      "overview": "The Solana network is engineered for high throughput and low latency, making it well-suited for scalable decentralized applications. While mostly theoretical, Solana aims to execute 65,000 transactions per second and have 400 ms block times. It employs a unique combination of proof-of-history and proof-of-stake consensus mechanisms to process thousands of transactions per second efficiently. By prioritizing speed and cost-efficiency, Solana has emerged as a popular platform for decentralized finance (DeFi) and Web3 innovations.",
      "consensus_mechanism": "Proof-of-Stake: Proof-of-History",
      "hashing_algorithm": "SHA256",
      "transaction_finality": "No Fixed Finality Threshold",
      "available_clients": [
        "Rust Client"
      ],
      "smart_contract_deployment": "Permissionless",
      "foundation": [
        "Solana Foundation: Non-profit foundation focused on decentralizing the network by providing grants, validator delegations, and server programs",
        "Solana Labs: Organization building and implementing products and tooling to expand the Solana ecosystem"
      ],
      "founding_team_identity": "Known",
      "repository": [
        {
          "github_repository": "Solana Core",
          "github_url": "github.com/solana-labs/solana"
        }
      ],
      "transaction_visibility": "Visible",
      "native_fee_token": "SOL",
      "significant_historical_changes": [
        {
          "date": "2020-10-07",
          "details": "Solana announced its integration with Wormhole to support cross-chain message and asset transfers with Ethereum"
        },
        {
          "date": "2022-12-13",
          "details": "Solana made its QUIC implementation the official message propogation standard for transactions in upgrade 1.13.4"
        },
        {
          "date": "2024-01-24",
          "details": "Solana's Token Extensions program was released to increase token customizability for issuers"
        }
      ],
      "rollup_info": [
        {
          "rollup_type": "N/A",
          "state_validation": "N/A"
        }
      ],
      "network_scaling_solution": "false",
      "type_of_network": "Blockchain",
      "chain_explorers": [
        "https://solscan.io/",
        "https://explorer.solana.com/",
        "https://solanabeach.io/",
        "https://solana.fm/"
      ]
    }
  ]
}
```

### Example: a rollup network

An optimistic rollup settling to Ethereum. `rollup_info` carries the proof system, `network_scaling_solution` is `"true"`, and `native_fee_token` is `ETH` rather than an asset of the network's own. `hashing_algorithm` and `available_clients` are omitted rather than returned empty. [Run this query](https://api.coinmetrics.io/v4/profile/networks?networks=base\&api_key=YOUR_API_KEY).

```json
{
  "data": [
    {
      "full_name": "Base",
      "network": "base",
      "modular_or_monolithic": "Modular",
      "overview": "Base is an Ethereum Layer-2 network scaling solution using the OP Stack to increase processing speeds and cross-chain interoperability. A centralized sequencer receives and orders transactions using a private mempool. Transactions are then executed and the data is posted to Ethereum as blob data to track state changes. A centralized sequencer and batching transactions to post state data help increase the transaction per second throughput. Base is continuously increasing the gas target per second to increase the number of transactions included in each block. Transactions can more easily interact with other networks built on the OP Stack including OP Mainnet and Unichain. The cross-chain functionality of tokens and messaging helps reduce liquidity fragmentation and increase security across networks.",
      "consensus_mechanism": "Proof-of-Stake",
      "transaction_finality": "No Fixed Finality Threshold",
      "smart_contract_deployment": "Permissionless",
      "foundation": [
        "Coinbase: A U.S.-based cryptocurrency exchange managing the Base sequencer and supporting application development on Base."
      ],
      "founding_team_identity": "Known",
      "repository": [
        {
          "github_repository": "Base",
          "github_url": "github.com/base"
        }
      ],
      "transaction_visibility": "Visible",
      "native_fee_token": "ETH",
      "rollup_info": [
        {
          "rollup_type": "Optimistic",
          "state_validation": "Interactive Fraud Proofs"
        }
      ],
      "network_scaling_solution": "true",
      "type_of_network": "Rollup",
      "chain_explorers": [
        "https://basescan.org/"
      ]
    }
  ]
}
```

## Coverage

Network 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 covered network. This is the authoritative list of what is covered, and it stays current across releases.

* [`/profile/networks`](https://docs.coinmetrics.io/api/v4/#operation/getNetworkProfiles): queried with no filters, returns every covered network. 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_network_profiles().to_list()

# Every covered network, with the fields most often used to group them
for p in sorted(profiles, key=lambda x: x["network"]):
    print(p["network"], p["full_name"], p.get("type_of_network"), p.get("consensus_mechanism"))
```

{% endtab %}

{% tab title="Shell" %}

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

{% endtab %}
{% endtabs %}

The covered set is deliberately narrow and much smaller than the asset profile universe. It concentrates on networks that carry significant issued value, so a network appearing in an asset profile's `issuing_networks` or `bridged_networks` does not necessarily have a profile of its own.

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

* **Group networks on consistent terms.** `consensus_mechanism`, `type_of_network`, and `modular_or_monolithic` give a stable vocabulary for splitting a set of networks by design rather than by narrative, for example separating rollups from base layers before comparing throughput or fee data.
* **Frame settlement assumptions.** `transaction_finality` records whether a network offers a fixed finality threshold or probabilistic settlement, which is the input to confirmation policies and to reconciliation windows.
* **Check client diversity.** `available_clients` shows whether a network runs on a single implementation or several, which is a standard input to resilience and concentration analysis.
* **Establish provenance and stewardship.** `foundation`, `founding_team_identity`, and `repository` answer who maintains a network and whether the founding team is publicly identified, which recur in diligence questionnaires.
* **Explain breaks in network data.** `upgrade_history` and `significant_historical_changes` give dated context for a step change in a network metric, such as a consensus change or a major protocol upgrade.
* **Complete an asset's picture.** Pair a network profile with the [asset profiles](/reference-data/profiles-overview/asset-profiles.md) of the tokens issued on it to describe both the token and the environment it settles in.

## 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.
* **Content is editorial and updates on a release cadence.** A profile reflects the state of research at the last release, so a recent upgrade, client release, or governance change can be absent. Nothing here is a real-time feed.
* **Categorical values are a curated vocabulary, not an enumeration.** `consensus_mechanism`, `type_of_network`, and `modular_or_monolithic` are written by analysts and are not constrained by the API contract, so a release can introduce a value your code has not seen. Treat them as open sets.
* **`network_scaling_solution` is a string.** It returns `"true"` or `"false"` as JSON strings rather than as booleans, so a truthiness check in most languages treats `"false"` as true.
* **Some fields are omitted rather than empty.** `hashing_algorithm`, `available_clients`, `significant_historical_changes`, and `upgrade_history` are absent on some profiles, meaning they either cannot be commented on or have not been researched yet. Treat every field except `network`, `full_name`, and `modular_or_monolithic` as optional.
* **`N/A` is a value, not an absence,** and it appears inside nested objects as well as in plain string fields (see [How absent values are represented](#how-absent-values-are-represented)).
* **Network identifiers are not asset names.** They overlap without being interchangeable, and `native_fee_token` is a display ticker rather than a Coin Metrics asset name (see [Networks are not assets](#networks-are-not-assets)).
* **Event dates are free text** and cannot be parsed reliably.

## FAQ

### How is a network profile different from an asset profile?

A network profile describes a settlement environment: how it reaches consensus, how transactions finalize, who maintains it. An [asset profile](/reference-data/profiles-overview/asset-profiles.md) describes a token: its purpose, supply, distribution, and regulatory status. The two are separate namespaces, and many networks have no asset of their own while many assets are issued on networks they did not create.

### Why does `network_scaling_solution` come back as `"true"` rather than `true`?

Every value on this endpoint is a JSON string, including this one. Compare it against the strings `"true"` and `"false"` rather than relying on language truthiness, which would read `"false"` as a truthy non-empty string.

### Why do Avalanche and Polygon appear more than once?

Because each distinct chain is profiled separately. Avalanche runs three chains with different roles, covered as `avaxc`, `avaxp`, and `avaxx`, and Polygon's proof-of-stake chain and zkEVM rollup are covered as `pol_pos` and `pol_zkevm`. See [What counts as a network](#what-counts-as-a-network).

### Can I join `native_fee_token` to the rest of the API?

Not directly. It is a display ticker such as `ETH` or `MATIC`, not a lowercased Coin Metrics asset name, and rollups report the fee token of the network they settle to. Map it explicitly rather than lowercasing and hoping.

### A network appears in an asset profile's `issuing_networks` but has no profile. Why?

Network profile coverage is narrower than the set of networks named in asset profiles, and the two fields use different value formats in any case. Asset profiles carry display names such as `Avalanche C-Chain`, while this endpoint uses identifiers such as `avaxc`.

### How often do network profiles change?

Only at a release, and network additions are infrequent. The change log on the [Profiles Overview](/reference-data/profiles-overview.md) records what each release added or revised.

### Can I filter networks by consensus mechanism or type?

No. The endpoint filters only on exact `networks` or `full_names` identifiers, with no wildcards and no partial matching. The covered set is small enough to pull in full and filter client-side.

## Related

* [Profiles Overview](/reference-data/profiles-overview.md): how asset and network profiles fit together, plus the release change log.
* [Asset Profiles](/reference-data/profiles-overview/asset-profiles.md): the same descriptive treatment for the tokens issued on these networks.
* [Network Data Pro Overview](/network-data/network-data-overview.md): the measured on-chain metrics for these networks, as opposed to their descriptions.


---

# 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/network-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.