Subgraph overcounts active proof sets; network metrics query broken

[timfong888]

Summary

Investigation by @SgtPooki (full report) identified several data accuracy issues in the PDP Explorer subgraph. I've independently confirmed these against the live mainnet311b subgraph deployment.

Issues

1. Proof sets marked isActive: true when they're effectively dead

Confirmed live data for provider 0x32c90c26bca6ed3945de9b29ba4e19d38314d618 (ezpdpz-main):

• Subgraph returns 116 proof sets, all with isActive: true
• Actual breakdown:
  • 86 actively proving
  • 10 empty (leafCount = 0) — IDs: 71, 75, 101, 176, 177, 182, 183, 184, 188, 451
  • 1 unscheduled (maxProvingPeriod = 0, nextDeadline = 0) — ID: 12
  • 19 stale (deadline > 3 proving periods behind current block) — IDs: 7, 9, 22, 24, 33, 44-49, 53, 54, 76, 84, 175, 236, 247, 248
• ~35% inflation in "active" proof set count

Root cause: handleDataSetEmpty zeros content fields but doesn't clear proving schedule fields (maxProvingPeriod, nextDeadline) or set isActive = false. Similarly, handlePiecesRemoved reduces leafCount without deactivating.

Proposed fix: A proof set should be considered "currently proving" only when ALL of:

• isActive == true
• leafCount > 0
• maxProvingPeriod > 0
• nextDeadline > 0
• nextDeadline is within a reasonable staleness window of the current block

Options:

1. Subgraph mapping fix — set isActive = false (or add a new isProving field) when datasets empty or go stale
2. Frontend filter — add a currentlyProving derived field or filter in the UI queries

2. networkMetric query returns store error

{ networkMetric(id: "network-metrics") { totalProofSets totalActiveProofSets ... } }

Returns:

{"errors":[{"message":"Store error: store error: Odd number of digits"}]}

This means the landing page network-level metrics (total proof sets, total active, total roots, etc.) may be broken or falling back to cached/stale data.

3. Challenges vs. Proving Periods semantic gap (dealbot context)

Per the gist analysis (section 4):

• PDP spec defines 5 challenges per proof per day
• Dealbot's dataSetChallengeStatus counts totalProvingPeriods / totalFaultedPeriods — does not multiply by 5
• If the Explorer displays these as "challenges," they're understated by 5x
• If displayed as "proving periods," the label is correct but docs are misleading

Ask: Clarify what the Explorer intends to display and align the label with the actual metric.

4. maxProvingPeriod source/deploy mismatch

Local pdp-explorer code initializes maxProvingPeriod = 240 (calibration value in comments), but deployed mainnet uses 2880. Source and deployment should be aligned.

Verification Steps

# Reproduce the proof set overcounting
curl -s 'https://api.goldsky.com/api/public/project_cmdfaaxeuz6us01u359yjdctw/subgraphs/pdp-explorer/mainnet311b/gn' \
  -H 'Content-Type: application/json' \
  -d '{"query": "{ provider(id: \"0x32c90c26bca6ed3945de9b29ba4e19d38314d618\") { totalProofSets proofSets(first: 200) { setId isActive leafCount nextDeadline maxProvingPeriod } } _meta { block { number } } }"}'

# Reproduce the network metrics error
curl -s 'https://api.goldsky.com/api/public/project_cmdfaaxeuz6us01u359yjdctw/subgraphs/pdp-explorer/mainnet311b/gn' \
  -H 'Content-Type: application/json' \
  -d '{"query": "{ networkMetric(id: \"network-metrics\") { totalProofSets totalActiveProofSets totalProviders } }"}'

References

• Full investigation: https://gist.github.com/SgtPooki/4737061fdee22bfe6aa10df593d2714e
• Live subgraph: pdp-explorer/mainnet311b on Goldsky project project_cmdfaaxeuz6us01u359yjdctw
• Subgraph synced to block 5,865,919 (current as of 2026-03-23)

[BigLep]

@FilOzone/storswift : we'll need help making updates here so that dealbot numbers are accurate.

@silent-cipher : if you have any input or suggestions here (or want to make the fixes), please share.

[silent-cipher]

2. networkMetric query returns store error

The issue seems to be with the query input. The id field in the schema is of type Bytes, but the query is currently passing a string ("network-metrics"), which leads to the error (Odd number of digits).

The id should be an even-length hex value. For example, the intended identifier pdp_network_stats converts to:
0x7064705f6e6574776f726b5f7374617473

So the corrected query would be:

{ networkMetric(id: "0x7064705f6e6574776f726b5f7374617473") { totalProofSets totalActiveProofSets ... } }

[silent-cipher]

1. Proof sets marked isActive: true when they're effectively dead

I’ve raised a PR (#91) to better track the dataset lifecycle. This should address the inconsistencies around stale/empty proof sets.
Note: isActive semantics remain unchanged for now, but the lifecycle tracking should help distinguish truly active vs effectively dead sets.

4. maxProvingPeriod source/deploy mismatch

I’d suggest introducing a single config file as the source of truth for network-specific constants. This config can then be used to populate values via mustache templates across environments.
This is similar to the approach used in the fwss subgraph

[silent-cipher]

Unassigning myself for now. I assume the @FilOzone/storswift team will take this forward as discussed here.

[kaola526]

@silent-cipher Update PR #91， The subgraph is resyncing.