Skip to content

PDP calibnet E2E: CommPv2 validation gaps, addPieces gas-limit failure, and listener/createDataSet edge cases #631

@anjor

Description

@anjor

Summary

I ran a full PDP calibnet E2E flow with Singularity and found multiple blockers/inconsistencies. I was able to complete a successful on-chain run after local code and config changes, but the current UX/path has several sharp edges.

This issue captures the full reproduction, exact chain evidence, and the fixes that were required.

Environment

  • Date: 2026-02-27
  • Repo: data-preservation-programs/singularity
  • Network: calibnet
  • PDPVerifier: 0x85e366Cf9DD2c0aE37E963d9556F5f4718d6417C
  • DB used: singularity_v2
  • Wallet used:
    • delegated: t410fmcffelu4okurnsxqcs352bgqmvxww566spsdeii
    • EVM: 0x608a522E9C72a916CAF014b7dD04D0656f6B77De

Repro Timeline and Findings

1) createDataSet sybil fee gate

Initial schedule execution failed with:

  • revert reason=[Error(sybil fee not met)]

This required sending value in CreateProofSet.

2) createDataSet listener behavior mismatch

After sending value, createDataSet still reverted (no reason) when listener was set to EOA 0x608a....

In local probing:

  • listener=0x608a... + value >= 1 FIL => revert at contract path (no reason)
  • listener=0x000...000 + value >= 1 FIL => estimate succeeds

3) addPieces failed due fixed gas cap path

Observed failed tx:

  • Eth tx: 0x86fbed6d5ac86716992761880da64b52702caf5c7425c5e1bc7d3781af0cb60d
  • Message CID: bafy2bzacec33cynncg55yfyxaj5tv4kdswu26drdxabxsqug7crtmtfop6lze
  • Receipt status: 0x0
  • Filecoin receipt: ExitCode=7, GasUsed=5000000

This matched a hard gas-limit path (5_000_000) in local adapter code.

4) CommPv2 compatibility gap in validations

PDP contract rejected legacy piece CID with:

  • Error(Cid must be CommPv2)

But CLI/API validation paths for piece CIDs only accepted cid.FilCommitmentUnsealed (“commp”), which prevented using CommPv2 CIDs in normal flows:

  • dataprep add-piece validation
  • schedule create/update allowed-piece-cid validation

5) Schedule state / metadata behavior

A completed schedule retained prior error_message text, which is confusing for operational status.

Successful On-Chain Evidence (after fixes/workarounds)

Proof set created:

  • set_id=11849

DataSetCreated:

  • Eth tx: 0xb0c98f4d18f401c8d4aeb0042887ae1dea0f74f71a5fd003b51501cdd74f7576
  • Msg CID: bafy2bzacechskzxpw7krv3tdoi433hfipqgjczr3ncvztrqfrdpg6qdmbso4k
  • Receipt: status=0x1, block 0x355a3c (3496508)

PiecesAdded:

  • Eth tx: 0xb1aacc2469a081743d3a1a8d48af671ff63d5c729422115592e89645e543c7c0
  • Msg CID: bafy2bzaceaiqtzx2rjcrzskpshqjpowgrkx7jm2r4zkd7ztrflvhtmcmenqzg
  • Receipt: status=0x1, block 0x355a90 (3496592)
  • Added piece: bafkzcibd6adqmxxmxtat74d6vqbczd5v3kvg5mdbhtkuawcyfeqvegqd4skzqqy3

Final Singularity state:

  • schedule_id=2 => completed
  • PDP deal row created (deal_type=pdp, state=proposed, proof_set_id=11849)

Local Changes That Unblocked E2E

  • service/dealpusher/pdp_onchain.go
    • include value on CreateProofSet
    • listener handling change for createDataSet
    • switched add-roots submission to manager path (gas estimation-based)
  • added CID compatibility helper + wired validation sites:
    • util/piececid.go
    • handler/dataprep/piece.go
    • handler/deal/schedule/create.go
    • handler/deal/schedule/update.go

Requested Fixes

  1. First-class CommPv2 support in all relevant piece-CID validations for PDP workflows.
  2. Remove hard fixed gas-limit behavior for addPieces path (or make it adaptive/configurable with safe default).
  3. Clarify/standardize expected listener address semantics for createDataSet on calibnet/mainnet.
  4. Clear or segregate stale error_message once schedule transitions to completed.
  5. (Optional UX) add explicit guidance/docs for PDP CID format requirements and wallet/address expectations.

Reference

I also wrote a runbook with exact commands and outputs:

  • docs/en/topics/pdp-calibnet-e2e.md

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions