Description: A data set's payer is fixed at creation. Verified against the deployed contracts: in Filecoin Pay v1 a rail's from is written only by createRail, and in FilecoinWarmStorageService 1.3.0 info.payer is written only in the data-set-creation path (storageProviderChanged reverts; Pay v1 is non-upgradeable). Neither contract exposes a re-point function. So moving already-stored data under a new payer means creating a new data set and re-committing its pieces.
Those pieces are re-pullable without the original source. A storage provider serves each stored piece's canonical CAR at GET /piece/{pieceCidV2} (verified live against a mainnet SP — HTTP 200, etag equals the pieceCID, CARv1 body), and PieceCIDs are deterministic, so a re-pull recomputes the same commitment. The existing on-chain data is therefore its own migration source — no gateway or original CID list required.
Proposed flow (foc2foc / payer-migrate):
- Enumerate a source data set's active pieces on chain (
getActivePieces → pieceCID + rawSize) and seed a plan/DB from them.
- Create the destination data set under the new payer.
- Submit with the PDP pull source pointed at the existing SP's
/piece/{pieceCidV2}. pdp-submit --source-base https://<sp-service-url> already builds {base}/piece/{pcid} (see pullSourceUrl in packages/cli/src/submit-pdp.ts); the only new work is seeding the plan from chain rather than from a CID list.
Scope:
- New payer as a different EOA works with existing
create-data-set (payer = the signer).
- A contract/sponsor payer is out of scope here: the contract must
setOperatorApproval and authorize a session key before creation. Track separately.
Caveats: the source SP must keep serving /piece through the migration, and storage plus a payment rail are duplicated until the old data set is terminated. Related: #49 (relocate a single failed copy to another provider) is the same "move a copy" theme at piece granularity.
Description: A data set's payer is fixed at creation. Verified against the deployed contracts: in Filecoin Pay v1 a rail's
fromis written only bycreateRail, and in FilecoinWarmStorageService 1.3.0info.payeris written only in the data-set-creation path (storageProviderChangedreverts; Pay v1 is non-upgradeable). Neither contract exposes a re-point function. So moving already-stored data under a new payer means creating a new data set and re-committing its pieces.Those pieces are re-pullable without the original source. A storage provider serves each stored piece's canonical CAR at
GET /piece/{pieceCidV2}(verified live against a mainnet SP — HTTP 200,etagequals the pieceCID, CARv1 body), and PieceCIDs are deterministic, so a re-pull recomputes the same commitment. The existing on-chain data is therefore its own migration source — no gateway or original CID list required.Proposed flow (foc2foc / payer-migrate):
getActivePieces→ pieceCID + rawSize) and seed a plan/DB from them./piece/{pieceCidV2}.pdp-submit --source-base https://<sp-service-url>already builds{base}/piece/{pcid}(seepullSourceUrlinpackages/cli/src/submit-pdp.ts); the only new work is seeding the plan from chain rather than from a CID list.Scope:
create-data-set(payer = the signer).setOperatorApprovaland authorize a session key before creation. Track separately.Caveats: the source SP must keep serving
/piecethrough the migration, and storage plus a payment rail are duplicated until the old data set is terminated. Related: #49 (relocate a single failed copy to another provider) is the same "move a copy" theme at piece granularity.