File Availability Still Needs CIDs, Replicas and Proofs

Filecoin’s March 26, 2026 mainnet launch of Onchain Cloud made file availability a three-part operating job: preserve the right content identifier, keep independent replicas, and verify possession without confusing a proof with a successful download. The default Synapse SDK path now places each upload with two storage providers, records a separate onchain proof for each copy and challenges those copies every 24 hours. That is a material improvement over a single IPFS pin or an unverified cloud promise, but it is not permanence by default.

What does a CID actually guarantee?

A content identifier guarantees identity, not availability. It is derived from the content, so changing even one byte produces a different address and a retrieved object can be checked against the expected CID. The CID does not say where the bytes are hosted, how many copies exist, whether a provider is reachable or how long anyone has agreed to retain them.

That distinction matters for application operators. A reference such as Manta Bridge may direct a reader to an application, but a name or route is no substitute for a recorded CID and a tested source for its underlying files. Operators must preserve both the identifier and a way to discover providers serving it.

Two replicas change the failure model

Onchain Cloud now sends an upload to one provider, then has a second independent provider pull the same data from the first. The uploader avoids transmitting the payload twice, while each provider registers its own proof. At launch, Filecoin reported 49.41 TiB stored across 478 active datasets and 81 payer wallets. Those figures measure early use, not retrieval latency or durability over time.

The advertised starting price is $2.50 per TiB per month per copy, making the default two-copy storage charge $5 per TiB per month before retrieval, transaction and operating costs. The second copy removes a single-provider failure, but independence must be checked at the infrastructure level: two provider IDs sharing one site, power feed or upstream network can still fail together.

What do possession proofs leave unproven?

Proof of Data Possession shows that a provider holds the committed data when challenged. It keeps hot data in accessible form and uses ordinary SHA-2 work, avoiding the specialized sealing and later unsealing associated with Filecoin’s Proof of Replication archival path. That lowers compute friction and supports mutable datasets, while daily proofs can stop payments when a provider faults.

It does not prove that a full object crossed the network within an application’s timeout. Filecoin says admitted providers are tested against at least 95% storage success, more than 95% retrieval success and a PDP fault rate below 1%; these are entry and monitoring thresholds, not a zero-downtime guarantee. Operators still need end-to-end reads from the regions and gateways their users depend on.

The operator checklist is short but non-negotiable

• Record the root CID, piece CID, dataset ID and both provider identities outside the storage client.
• Alert on proof faults and payment depletion, then run scheduled full and partial retrievals.
• Place replicas across genuinely separate power, network and geographic failure domains.
• Keep a third recovery source for data whose loss would exceed the cost of another copy.

The launch turns replication and proof status into observable infrastructure rather than a claim in a service dashboard. Its operational significance is real: smaller providers can serve verifiable hot data without sealing hardware, and clients get portable identifiers plus two attestable copies. The unresolved weakness is repair. The announced upload flow can select a replacement when the secondary fails, but automated fault-triggered re-replication from a healthy copy remains a post-general-availability item. Until that loop is proven under real outages, CIDs, replicas and proofs reduce risk only when an operator also watches retrieval and restores redundancy.