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 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

Data type	Entities	Frequency / cadence	Unit	Primary endpoint	Coverage
Network descriptions (reference data)	Networks	Reference data, published in releases as profiles are added or revised	Descriptive text and categorical labels	/profile/networks	🔗

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).

Fields are grouped below by what they describe. Every field returned by the endpoint appears exactly once across these tables.

Identity and description

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

Consensus and execution

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

Architecture and scaling

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

Stewardship

Field	Type	Description	Notes
foundation	array[string]	Organizations supporting development of the network. Each entry is a name followed by a short description of that organization's role.	All profiles
founding_team_identity	string	Whether the identity of the founding team is publicly known, as Known or Unknown.	All profiles
repository	array[object]	Repositories relevant to the network. Sub-fields: github_repository (string, the repository name), github_url (string, the URL, served without a scheme).	All profiles

History

Field	Type	Description	Notes
significant_historical_changes	array[object]	Notable events in the network's history. Sub-fields: date (string), details (string).	Optional
upgrade_history	array[object]	Upgrades the network has undergone. Sub-fields: date (string), details (string).	Optional

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.

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.

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.

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 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

Python Client

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()

Shell

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

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()

Unlike Asset Profiles, .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.

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.

{
  "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.

{
  "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: 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.

Python Client

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"))

Shell

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

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 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).
• 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).
• 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 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.

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 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: how asset and network profiles fit together, plus the release change log.
• Asset Profiles: the same descriptive treatment for the tokens issued on these networks.
• Network Data Pro Overview: the measured on-chain metrics for these networks, as opposed to their descriptions.