Polkadot logo

Topology

Key metrics on network structure, geographic peer distribution, client diversity, and connection patterns across the Polkadot network. All metrics in this section refer to Polkadot DHT Server nodes.

Geographic Distribution

Node IP address to country, city, and autonomous system (ASN) mapping, based on data sourced from https://ipregistry.co/.

Peers By City

Peers By City

This map shows the online peers per city in the last crawl of the latest day. The city and its coordinates come from the IP address mapping of ipregistry.co. Peers without a known city are not on the map. The text below the map shows how many peers are not on the map.

Loading ...

Geolocation Over Time

DHT Server geolocation per agent version over time

Countries Distribution (24h)

Snapshot of active agents geolocation within the last 24hrs

Cities Over Time

Cities Over Time

Shows the number of online peers in the ten cities with the most peers over time. The other cities are in "Other". The city of a peer comes from the IP address mapping of ipregistry.co. Peers without a known city are not in this chart.

Online peers in the largest cities

Autonomous Systems Over Time

Autonomous Systems Over Time

Shows the number of online peers in the ten largest autonomous systems (ASNs) over time. The other ASNs are in "Other". The ASN of a peer comes from the IP address mapping of ipregistry.co. Peers without a known ASN are not in this chart.

Online peers in the largest autonomous systems (ASNs)

ASN Concentration

ASN Concentration

Shows how concentrated the online peers are in autonomous systems (ASNs). Only peers with a known ASN count. Select a view:

  • Largest ASNs: the share of the peers in the largest ASN and in the ten largest ASNs.
  • ASNs for 50%: the smallest number of ASNs that together host half of the peers. A low number means that a few network operators host much of the network.
  • HHI: the Herfindahl-Hirschman index of the ASN shares, from 0 (spread over many ASNs) to 10,000 (all peers in one ASN).

How many autonomous systems host the online peers

Agent Version Distributions

Network structure representation through client and agent distribution.

Client Diversity Trend

Client Diversity Trend

Shows the evolution of different user agent types (client software) participating in the network, over time.

Each agent type represents a different implementation and and indicates its relative prevalence within the network for the given reporting period. This chart helps track software diversity, adoption of new client versions, and overall network health, in terms of active nodes in the network.

The Unknown category represents nodes where the agent version could not be retrieved through the libp2p identify protocol. This situation can occur due to various reasons, such as the node terminating the connection before completing the full protocol negotiation.

Client participation over time

Active Agents Distribution (24h)

Snapshot of active agents within the last 24hrs

Agent Versions Trend

Agent version participation over time

Agent Version Distribution (24h)

Snapshot of versions active per agent within the last 24hrs

Peer Churn

Peer Churn

This plot presents the Cumulative Distribution Function (CDF) of peer departure times from the network over a measurement period of one-week. The plot basically shows the percentage of nodes online at a point in time (t=0) that will have disconnected after 1 hour, 2 hours, 3 hours, .. up to 24 hours after t=0.

  • X-Axis (Time in Hours): Represents the elapsed time since the reference point (t=0), measured in hours.

  • Y-Axis (Percentage of Offline Peers): Indicates the cumulative percentage of peers that have disconnected from the network by the corresponding time interval. Specifically, it shows the proportion of peers that were from projects.common.charts.chart_ids import ChartID online at t=0 and have since gone offline.

This visualization aids in understanding peer churn dynamics, which is crucial for optimizing network stability, resource allocation, and improving overall decentralized network performance.

Note that the sum of the CDF is NOT 100%, as it only includes peers that were online for 24h, or less.

CDF of Peer Departure Times

Protocols & Infrastructure

Key metrics on supported protocols per agent version, as well as intrastructure providers.

Quic Support Over Time

Quic Support Over Time

Tracks the adoption of QUIC protocol support across different client implementations, over time. QUIC provides improved performance, security, and connection reliability compared to traditional TCP. This chart shows which client types support QUIC and how adoption evolves, helping assess the network's transition to more efficient transport protocols.

Count of nodes that support QUIC per agent version

Cloud Provider Dependency Over Time

Count of nodes deployed per cloud provider and per agent

Supported Protocols Over Time

Number of peers supporting the top 40 protocols in the network.

Errors

Connection and crawl errors breakdown, as well as Stale Record occurences in the network

Dial Error Causality Distribution

Dial Error Causality Distribution

The plot shows the percentage split of the cause of errors, when errors happen. For example, a 20% error due to, say, connection_refused does not mean that 20% of the time we attempted a connection to a node our attempt was refused. The percentage shown is out of the times that an error did occur, not the total number of attempts.

Percentage split of dial errors per error cause

Crawl Errors Over Time

Crawl Errors Over Time

Monitors the percentage of crawl errors encountered during network topology discovery over time. Crawl errors occur when the monitoring system cannot successfully connect to or retrieve information from discovered peers. This metric helps identify network connectivity issues, configuration problems, or periods of increased network instability. Use the discovery method filter to analyze errors specific to DHT or GossipSub peer discovery.

Percentage split of crawl errors per error cause

Stale Records - Mainnet

Stale Records - Mainnet

Ensuring reachability of referenced nodes shared within the network is critical. This plot delineates the occurrences of reachable and non-reachable (stale) node records. Note that nodes running behind a NAT are counted as unreachable even though they may be online. For instance, if a node’s record is present in the routing tables of 100 other nodes and the node is reachable, the plot will reflect an increase of 100 in the online category.

Reachable vs Unreachable DHT Records Over Time

Related Work

Blog posts, papers and talks by the ProbeLab team about Polkadot.

og-polkadot
Blog post

160 Dials: How Two go-libp2p Defaults Halved Our View of Polkadot

Our Polkadot crawls reached about half of the reachable network, and a different half every time. The cause was two dial limits in go-libp2p. We …

SIGMETRICS '26 Conference Paper
Paper

Multiple Sides of 36 Coins: Measuring Peer-to-Peer Infrastructure Across Cryptocurrencies

Blockchain technologies underpin an expanding ecosystem of decentralized applications, financial systems, and infrastructure. However, the fundamental networking layer that sustains these systems, the peer-to-peer (P2P) …

Polkadot Logo Blog Hero
Blog post

Polkadot Network Health Weekly Reports are Live

A deep dive into Polkadot's DHT Network Structure.