Filecoin Report Cal. Week 23 - 2025 #

General Information #

The following results show measurement data that were collected in calendar week 23 of 2025 from 2025-06-02 to 2025-06-09.

Our methodology is available here. Note we are only able to display information about dialable peers, hence nodes operating behind a NAT aren’t accounted for, even though they may be connected.

Agents #

This bar chart represents the distribution of various user agents within the Filecoin Mainnet DHT. Each bar corresponds to a different user agent or client type and indicates its relative prevalence within the network for the given reporting period. The chart provides a snapshot of how different Filecoin Mainnet clients are being utilized in the network’s decentralized infrastructure.

The bar labeled Unknown represents the count of nodes that we confirmed to be online but couldn’t retrieve the agent version information from. This situation can occur due to various reasons, such as the node terminating the connection before completing the full protocol negotiation. In this case, despite reaching an advanced stage in the process, we were unable to obtain any information about the node’s configuration.

This stacked plot shows the distribution of various user agents over time.

This chart presents the version distribution for all major user agents, with each bar representing the average number of online peers over the course of a week.

This stacked chart illustrates how the distribution of agent versions for all key user agents evolves over time. It offers insights into the uptake of newer versions among these agents.

This plot shows the distribution of agent versions by quality adjust power (QAP) and raw bytes power (RBP).

Protocols #

This plot illustrates the evolving count of nodes supporting each of the listed protocols over time for the different user agents. The identification of supported protocols relies on the [libp2p identify protocol](https://github.com/libp2p/specs/tree/master/identify).

Quic support #

This stacked chart illustrates quic support for Filecoin peers over time, broken down by user agent.

Geolocation #

Geographical data is sourced from a leading IP Geolocation provider, which maps IP addresses to corresponding countries.

This bar plot illustrates the distribution of observed beacon nodes across different countries, broken down for each major user agent.

This plot displays the weekly geographical distribution of beacon nodes, categorized by country and broken down for each major user agent.

Cloud Providers #

This pie chart shows the average number of nodes over a day hosted on known cloud providers, compared to those that are not.

Cloud providers data is powered by ipregistry.co, which maps IP addresses to known hosting providers.

Cloud Hosting Rate #

This line chart displays the count of Filecoin mainnet peers that are hosted on known commercial cloud providers, compared to those that are not. It tracks the distribution over a specified period, offering insights into the infrastructure preferences for node hosting. The graph is broken down by each major user agent.

Regular analysis of this chart can reveal trends in the adoption of cloud services for beacon nodes. Such information is crucial for understanding the network’s resilience and the potential reliance on cloud infrastructure.

Cloud Provider Dependence #

This bar chart presents the distribution of Filecoin mainnet peers among various cloud providers, including nodes not hosted within data centers (grouped under Non-Cloud).

This chart illustrates the trends in the distribution of all Filecoin mainnet peers across cloud providers over the given time period. Nodes that cannot be classified with a cloud provider is labelled as “Non- Cloud”. Note that nodes hosted outside of data centers are not included in this representation.

Churn Analysis #

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 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 up to 24h.

Errors #

The next plot showcases the percentage of errors encountered when connecting to peers during crawling activities, relative to the total number of connection attempts. By tracking various error types over time, it provides insights into crawling reliability and highlights trends in connection issues.

This plot displays the percentage of errors encountered when requesting peers from a remote node’s routing table after establishing a connection. It offers insights into the reliability of DHT requests within active libp2p connections.

Stale Peer Records #

This stacked plot depicts the count of peer records stored within each node’s routing table and made accessible through the DHT. These peer records are used to discover new remote peers within the network, enabling efficient and secure routing towards the target peer or content

Ensuring the reachability of referenced peers shared within the network holds paramount importance. The plot delineates the occurrences of reachable and non-reachable (stale) peer records. Note that nodes running behind a NAT are counted as unreachable even though they may be online.

For instance, if a peer’s record is present in the routing tables of 100 other nodes and the peer is reachable, the plot will reflect an increase of 100 in the online category.

Keyspace Density Monitoring #

💡 The latest keyspace density data is available here.

In Kademlia, every object indexed by the DHT requires a binary identifier. In the libp2p DHT implementation, peers are identified by the digest of sha256(peer_id) and CIDs are identified by the digest of sha256(cid). This Kademlia identifier determines the location of an object within the Kademlia XOR keyspace.

The following plots examine the peer distribution within the keyspace, aiding in the identification of potential Sybil and eclipse attacks.

Keyspace population distribution #

Description: The plot illustrates the number of peers whose Kademlia identifier matches each prefix for all prefixes of a given size, for a given network crawl. Since the density of keyspace regions follows a Poisson distribution, it is expected to observe some regions that are significantly more populated than others.

How to read the plot: The selected depth indicates the prefix size. There are 2^i distinct prefixes at depth i. The slider at the bottom of the plot enables visualization of the population evolution over time across multiple crawls.

What to look out for: The red dashed line represents the expected density per region, corresponding to the number of peers matching a prefix. A bar significantly exceeding the expected density suggests that a region of the keyspace might be under an eclipse attack, especially if the value is above the risk threshold.

Keyspace density distribution #

Description: As previously mentioned, the keyspace population follows a Poisson distribution, which can make identifying outliers challenging. The plot below counts the number of regions for each population size and facilitates the identification and analysis of outliers. While it is normal for some regions to have populations above the average, the plot enables us to quantify these deviations.

How to read the plot: The red dashed line represents the expected number of regions for each population size. Note that the Poisson distribution is more evident at greater depths (longer prefix size), while analyzing data at lower depths provides limited insights. It is recommended to read the plot for depths between 6 and 8.

What to look out for: If an isolated bar appears on the far right beyond the risk threshold line, it may indicate a potential eclipse attack, warranting further investigation.

Sample Size #

The following numbers show the sample size and other general statistics during the measurement period

• Number of crawls: 84

  The number of crawls executed during the week indicated above.

• Number of visits: 70350

  Every attempt to dial or connect to a peer counts as a visit. Regardless of errors that may occur. We visit peers many times during a given week to extract information from them or probe for their uptime. We visit all peers that we discover in the DHT and peers that we found to be still online from the previous week.

• Number of unique peer IDs discovered in the DHT: 1514

  The total number of unique PeerIDs that our crawler found in the DHT over the period of the given week and attempted to dial or connect to (visit).

• Number of unique addresses discovered in the DHT: 325

  The total number of unique IP:Port combinations that our crawler learned about from other peers over the period of the given week and attempted to dial or connect to (visit). This is not the total number of Peer IDs that existed simultaneously in the network at any point during the week. It is the aggregate over the entire week.

Timestamps are in UTC if not mentioned otherwise.