feat: fwss dataset/piece index enrichment

[dennis-tra]

This PR adds functionality to index the FilecoinWarmStorageService contract alongside PDPVerifier so a single pdp-explorer query can answer both "what PDP state is this dataset in?" and "what FWSS metadata was it created with?"

This is motivated by FilOzone/dealbot#427 (anonymous retrieval check). With this change, dealbot replaces a client-side join of two subgraphs with one native GraphQL query that filters on withIPFSIndexing, fwssPayer, and rawSize all at once.

Changelog

• FilecoinWarmStorageService contract added to all three manifests handled in fwss.ts
• ServiceTerminated flips DataSet.isActive = false.
• PDPPaymentTerminated does not flip isActive. Clients compare to current epoch themselves. Is this correct? Should it also flip isActive?
• ABI taken from foc-observer

There was one complication with the event ordering from the contract:

PDPVerifier._createDataSet calls listener.dataSetCreated(...) before emitting its own DataSetCreated (see pdp/src/PDPVerifier.sol:589-592), so FWSS's event has the lower log index and fires first. To avoid the FWSS handler running against a missing DataSet entity:

• fwss.ts:handleFwssDataSetCreated: When first to run, creates a stub with required non-null defaults and sets FWSS fields.
• pdp-verifier.ts:handleDataSetCreated — changed from new DataSet(...) to load-or-create. When the FWSS handler already created a stub, we load it (preserving FWSS fields) rather than overwrite.

Only DataSetCreated has this inverted ordering. PiecesAdded and StorageProviderChanged emit PDPVerifier-first, so those FWSS handlers are straightforward patch-the-existing-entity.

Downstream example

This unlocks richer filtering on existing dealbot queries. Example: GET_PROVIDERS_WITH_DATASETS in dealbot (apps/backend/src/pdp-subgraph/queries.ts) currently is:

query GetProvidersWithDataSet($addresses: [Bytes!], $blockNumber: BigInt!) {
  providers(where: {address_in: $addresses}) {
    address
    totalFaultedPeriods
    totalProvingPeriods
    proofSets(where: {nextDeadline_lt: $blockNumber, status: PROVING}) {
      nextDeadline
      maxProvingPeriod
    }
  }
}

With this PR, it can filter by FWSS metadata in the same query. Anonymous-retrieval piece selection becomes:

query AnonPieceCandidates(
  $sp: Bytes!, $dealbot: Bytes!, $minSize: BigInt!, $maxSize: BigInt!
) {
  provider(id: $sp) {
    proofSets(
      where: {
        isActive: true,
        status: PROVING,
        withIPFSIndexing: true,     # <-- new
        fwssPayer_not: $dealbot     # <-- new
      }
      first: 1000
    ) {
      setId
      fwssPayer
      roots(
        where: { removed: false, rawSize_gte: $minSize, rawSize_lte: $maxSize }
        first: 100
      ) {
        rootId
        cid
        rawSize
        ipfsRootCID                 # <-- new
      }
    }
  }
}

All filter dimensions (active state, piece size, IPFS indexing, payer exclusion) are native indexed filters.

---

I have deployed the new subgraphs for testing to Goldsky:

• Mainnet: https://api.goldsky.com/api/public/project_cmo89ydpga1e501x4d8600q7k/subgraphs/pdp-explorer/mainnet_0.2.0/gn
• Calibration: https://api.goldsky.com/api/public/project_cmo89ydpga1e501x4d8600q7k/subgraphs/pdp-explorer/calibnet_0.2.0/gn

---

Transparency: Implementation heavily augmented by Claude Opus 4.7

[rvagg]

FWSS isn't the only user of PDPVerifier. We've held off on doing this because entangling the two creates a false view of the system. PDPVerifier is a utility contract that happens to be used by FWSS to get its work done. On mainnet, there's more volume going through PDPVerifier via the Storacha contract than FWSS at the moment and there's nothing stopping anyone else using it to do whatever they want.

We've debated enriching like this because it would be nice on the PDP Explorer to be able to dive deeper into them, and @juliangruber is currently looking at this from the top-down Filecoin Pay perspective. As it stands though this feels like a bit of a hack and maybe we should be thinking more creatively about how to make the subgraph code in here either reusable or extensible such that someone can take it and deploy their own subgraph based on it but either enriched with their custom context, like FWSS, or to fit in with some larger view.

[dennis-tra]

Hi @rvagg, is your concern mainly that I tried to bolt a dealbot usecase onto the pdp-explorer or is the general direction not right? Remember I'm coming from the retrieval++ use case.

As it stands though this feels like a bit of a hack and maybe we should be thinking more creatively about how to make the subgraph code in here either reusable or extensible such that someone can take it and deploy their own subgraph based on it but either enriched with their custom context, like FWSS, or to fit in with some larger view.

Would it work if we took what's in this PR, moved it to the dealbot repository, and deployed a dedicated subgraph for dealbot that performs the aggregation? Currently dealbot seems to reuse this PDP Explorer's subgraph.

[SgtPooki]

Would it work if we took what's in this PR, moved it to the dealbot repository, and deployed a dedicated subgraph for dealbot that performs the aggregation? Currently dealbot seems to reuse this PDP Explorer's subgraph.

This sounds like a good plan TBH, but i'm not sure if we want to take on owning/deploying our own subgraph. How much work would it be to deploy a dealbot-specific subgraph?

[dennis-tra]

Deploying subgraphs to Goldsky seems very easy (unless I'm missing something). In the PR description you can find two links at the bottom which point to my test deployments.