Filecoin logo

Fast Finality in Filecoin (F3)

Key metrics for Fast Finality in Filecoin.

Fast Finality (F3) is Filecoin’s mechanism for reaching deterministic finality in minutes instead of hours. It adds a fast confirmation layer on top of the network’s existing consensus, helping users and applications track when chain state can be considered final with much greater confidence.

Instance Explorer

Drill into the voting data for a specific F3 consensus instance.

Operational Statistics

F3 Rounds per Instance

F3 Rounds per Instance

This graph shows daily distributions of how many rounds an F3 instance took to finalize. A round here corresponds to the round variable in the GossiPBFT pseudocode. We count the rounds from the F3 GossipSub messages that our Hermes node receives.

The total height of each bar shows the number of instances that started on that particular day. The different colors in each bar show how many instances took how many rounds to finalize. Hover over a bar to see the number and the share of instances for each number of rounds. Usually around 50% of instances finalize within the first round. However, it can sometimes take a few more rounds (usually up to six).

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Distribution of F3 Rounds per Instance

F3 Finalized Tipset Distance

F3 Finalized Tipset Distance

Shows, per day, how many epochs the tipset that an F3 instance finalizes is behind the consensus chain. For each instance, we take the time of the first DECIDE message that our Hermes GossipSub node sees and convert it to an epoch (30 seconds per epoch). The distance is this epoch minus the epoch of the newest tipset in the finalized chain. Instances for which we cannot find the tipset epoch are not shown.

Each day shows a bar consisting of the minimum, median, P90 (90th percentile) and maximum distance to the consensus chain across all finalized F3 instances in that particular day.

For example, a P50 (median) value of 9 means that 50% of finalized F3 instances during that day had a tipset distance to the consensus chain of 9 epochs or less. When you hover over a bar, you'll also see the total number of instances. If the time range includes 2026-03-08, an outlier day, the y-axis has a break.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Distribution of the finalized tipsets to the consensus chain.

F3 Instance Duration Distribution

F3 Instance Duration Distribution

This graph shows daily distributions of how long an F3 instance took to finalize. We measure the time from the first QUALITY message of round 0 that our Hermes GossipSub node sees, to the DECIDE message that brings the DECIDE votes to at least 2/3 of the power in the F3 power table. Only instances that reached this quorum are counted, on the day that they started.

Each day shows a bar consisting of the minimum, median, P90 (90th percentile) and maximum time the F3 instances took to finalize across instances in that particular day.

For example, a P50 (median) value of 2 minutes means that 50% of finalized F3 instances during that day took two minutes or less to finalize. When you hover over a bar, you'll also see the total number of instances that were considered in the calculation for that day. If the time range includes 2026-03-08, an outlier day, the y-axis has a break.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Daily Distribution of F3 Instance Durations

F3 Certificate Exchange

F3 Certificate Exchange

Note that this graph shows the PeerIDs as opposed to the number of Storage Providers. Multiple storage providers can run behind a single peer identity.

Shows the number of online peer IDs in each Nebula crawl, grouped by how they answer F3 certificate exchange requests. During a crawl, Nebula asks each peer for its latest F3 finality certificate. We compare the instance in this certificate with the network-wide finalized instance: the latest instance that reached quorum before the crawl started, as seen by our Hermes GossipSub node. The chart groups peers into five categories:

  • Caught Up: The peer responded to our certificate exchange request and the latest finalized instance in the peer's point of view is at most one instance behind the network-wide finalized instance.
  • Lagging: The peer responded to our certificate exchange request but the latest finalized instance in the peer's point of view is more than one instance behind the network-wide finalized instance.
  • Exchange Error: The peer supports the F3 Certificate Exchange protocol but our certificate exchange request failed.
  • No Support: The peer does not support the F3 Certificate Exchange protocol: /f3/certexch/get/1/filecoin
  • Unknown: We consider this peer as being online but we could not determine the certificate exchange support status, for example because the identify exchange failed.

Use the agent select to show only the peers of one agent type.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Distribution of F3 Certificate Exchange Support

Participation

F3 Power Participation

F3 Power Participation

Each F3 instance potentially consists of multiple consensus rounds. Each dot in this scatter plot represents the start of such a round as identified by the first GossipSub message that our Hermes node has seen being propagated in the network for that particular round and instance.

The graph shows the voting power in Quality-Adjusted Power (QaP), in EiB, for three different dimensions:

  1. Voting: The total power that has participated in a particular F3 instance/round
  2. Quorum: The total power that has participated in the DECIDE phase of a particular F3 instance/round
  3. Total: The total power in the F3 power table of that instance (not all power participates in F3)

The tooltip also shows Voting and Quorum as a share of the total power. A share below 2/3, the quorum that F3 needs to finalize an instance, shows in red. Use the agent select to show only the power of SPs of one agent type. Total always shows all power.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Quality-Adjusted Power (QaP) participating in Filecoin Fast Finality (F3)

F3 Storage Provider Participation

F3 Storage Provider Participation

Each F3 instance potentially consists of multiple consensus rounds. Each dot in this scatter plot represents the start of such a round as identified by the first GossipSub message that our Hermes node has seen being propagated in the network for that particular round and instance.

The graph shows the number of storage providers (SPs) for three different dimensions:

  1. Voting SPs: The number of unique storage providers that have participated in a particular F3 instance/round
  2. Quorum SPs: The number of unique storage providers that have participated in the DECIDE phase of a particular F3 instance/round
  3. Total SPs: The number of unique storage providers that have storage power in the network (not all SPs participate in F3), from the latest daily Spacescope data

The tooltip also shows each count as a share of the total SPs, and the instance and round of the dot. Use the agent select to show only the SPs of one agent type. Total SPs always counts all SPs.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Unique Storage Providers (SPs) participating in Filecoin Fast Finality

GossipSub (/f3/granite/0.0.3/filecoin)

GossipSub metrics for the /f3/granite/0.0.3/filecoin topic.

Duplicates Per Topic CDF

Duplicates Per Topic CDF

Shows the distribution of the number of duplicates per message for each topic on the selected day. A duplicate is one more copy of a message that our Hermes node already received. The x-axis shows how many duplicates of a message our node received. The y-axis shows the share of unique messages, identified by their message IDs, with this number of duplicates or fewer. Click a topic in the legend to show or hide it, and use the date picker to select another day.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Time to First Duplicate

Time to First Duplicate

Shows the distribution of the time to the first duplicate per topic on the selected day. This is the time in milliseconds from the moment our Hermes node delivered a message to the moment the first duplicate of this message arrived. A duplicate is one more copy of a message that our node already received. Only messages with at least one duplicate count. Messages whose first duplicate arrived before our node delivered the message, for example during validation, are not included. The x-axis shows the first 2 seconds. The tooltip shows the number of samples, which is the number of messages of each topic. Click a topic in the legend to show or hide it, and use the date picker to select another day.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

CDF of how long it took for the first duplicate to arrive.

Duplicate Message Sizes Per Topic CDF

Duplicate Message Sizes Per Topic CDF

Shows the distribution of message sizes per topic on the selected day. Each message that our Hermes node received and delivered counts once, by its message ID, also when it had no duplicates. The x-axis shows the size in kB (1 kB = 1,024 bytes). The y-axis shows the share of messages of this size or smaller. The tooltip shows the number of samples, which is the number of messages of each topic. Click a topic in the legend to show or hide it, and use the date picker to select another day.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Msg Size / Count Correlation

Msg Size / Count Correlation

Under the same network bandwidth, larger messages take longer to be fully transmitted between peers. Since a peer can only detect a message duplicate after downloading it completely, the likelihood of receiving duplicates increases with message size.

This heatmap shows how the size of the messages in one topic relates to the number of duplicates that our Hermes node received of them on the selected day. Each cell shows the number of unique messages with this size and this number of duplicates. The x-axis groups the message size in steps of 20 kB (1 kB = 1,024 bytes). The y-axis shows the number of duplicates: the row 2-3 holds the messages with 2 duplicates. The menu selects the topic, and the date picker selects the day.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Bandwidth Usage Distribution

Bandwidth Usage Distribution

Shows the share of each message type or topic in the GossipSub bandwidth of our Hermes node over the latest 24 hours of data. Hover over a slice to see its share in percent.

  • By Type shows the message types: deliver is the first copy of a message that our node received, duplicated are more copies of a message that our node already had, msg are messages that our node sent, and ihave and iwant are control messages.
  • By Topic shows the GossipSub topics.

The second menu selects the direction: Inbound (received), Outbound (sent), or Any Direction, where each slice name starts with in or out. Control messages that our node dropped are not included.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading...

Related Work

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

From rawpixel.com / Freepik
Blog post

ProbeLab's 2025 Review and 2026 Outlook

What we've achieved in 2025 and what we're targeting in 2026

Filecoin Logo Blog Hero
Blog post

Filecoin Network Health Weekly Reports are Live

Dive into Filecoin's DHT most important metrics.

ResNetLab Technical Report
Paper

Accelerating Content Routing with Bitswap: A multi-path file transfer protocol in IPFS and Filecoin

Bitswap is a Block Exchange protocol designed for P2P Content Addressable Networks. It leverages merkle-linked graphs in order to parallelize retrieval and verify content integrity. …

arXiv Preprint
Paper

GossipSub: Attack-Resilient Message Propagation in the Filecoin and ETH2.0 Networks

Permissionless blockchain environments necessitate the use of a fast and attack-resilient message propagation protocol for Block and Transaction messages to keep nodes synchronised and avoid …