Permanent storage is an underwriting claim, not a cryptographic primitive. IPFS explicitly says content can be discoverable without being persistently available, and warns that if the sponsor paying for pinning stops, the content may be lost. Filecoin turns persistence into negotiated storage deals with explicit terms, proofs, and renewals. Arweave instead asks users to pre-fund a storage endowment designed to pay miners over time for ongoing storage. Those are materially different liabilities, and most permanence narratives fail by blurring them.
The word “permanent” hides different liabilities
The first storage risk is category error. Teams often treat IPFS, Filecoin, Arweave, and “on-chain” data as interchangeable permanence layers. They are not. They encode different answers to four basic questions: who pays after upload, what is actually proven, who can refuse service, and what governance layer can change the effective user experience.
| System | Persistence model | What the docs actually promise | Main failure mode | Decentralization pressure point |
|---|---|---|---|---|
| IPFS | Content addressing plus pinning | IPFS says content is discoverable, but not guaranteed to be persistently available. Persistence requires local or remote pinning. | If the pin sponsor stops paying or unpins, the content may disappear from the network. | Remote pinning services and public gateways can become practical control points. |
| Filecoin | Term-based storage deals | Clients and storage providers agree on how much data is stored, for how long, and at what cost through term-based storage deals. Deals can be renewed and repaired because they expire. | Deal expiry, failed renewals, or weak retrieval operations can break practical permanence even if storage proofs worked during the deal term. | Verified-demand flows through allocators, root-key holders, and governance-defined DataCap rules. |
| Arweave | Upfront payment into a storage endowment | Arweave says uploaders pay an upfront contribution to a storage endowment, and current pricing is framed around 200 years of replicated storage at present prices, with a modeled path to indefinite duration. | The model depends on storage-cost decline, token value, and miner incentives continuing to support the endowment assumptions over very long horizons. | Access still depends on gateways, indexing, seeding, and bootstrap coordination outside the core storage proof. |
| Ethereum data layers | Consensus data availability, not archival permanence | EIP-4444 allows clients to stop serving historical bodies and receipts older than one year, and EIP-4844 blob data may be deleted after a short delay of about 18 days. | Ordinary nodes stop being archives. Applications that assume indefinite history retention on standard nodes break their own storage model. | History availability moves toward specialized archives and out-of-protocol distribution channels. |
Arweave is the cleanest example of how permanence becomes token economics. The protocol says the endowment’s purchasing power depends on storage volume, storage costs, and token value over time, and that users pay for 200 years of replicated storage at present prices while the model assumes only a 0.5% Kryder+ decline is needed for indefinite sustainability. It also notes that historical storage-cost decline has been far higher than that level. That is not magic. It is a long-dated bet that economic conditions will remain favorable enough for the storage endowment logic to hold.
Proofs of storage do not solve retrieval
Storage proofs answer a narrower question than users usually think. Filecoin’s Proof-of-Replication shows a miner created a unique replica, and Proof-of-Spacetime shows that the miner continues to store that sealed data over time. WindowPoSt audits pledged sectors on a rolling basis, with every sector audited at least once in a 24-hour period. That is strong verifiable storage. It is not the same thing as guaranteed low-latency retrieval.
Filecoin’s own docs make the gap explicit. Storage providers can and should keep unsealed copies for retrieval requests, and the same market software sets retrieval prices. In other words, proof-backed cold storage and practical hot access are partially separate services. A protocol can be cryptographically sound and still fail the user when data is too slow, too expensive, or too operationally brittle to retrieve reliably.
Arweave has a similar distinction in different language. The protocol says SPoRA verifies the accessibility and even replication of data, and miners are incentivized to accept new data only when fees cover enough replicas that incidental loss is extremely improbable over time. But Arweave’s own ecosystem docs also say the broader stack includes gateways, bundlers, search, seeding, caching, and compute layers around the base network. Permanence at the base layer does not remove failure at the access layer.
IPFS states this problem most bluntly. Public gateways can become the thing users actually rely on, which defeats a key benefit of decentralization when the gateway goes offline or is blocked. IPFS also warns that using a public or private HTTP gateway sacrifices end-to-end validation of content delivery and opens a man-in-the-middle risk where a compromised gateway can substitute false content or capture user queries. A storage network can be decentralized in theory while the user-facing retrieval path recentralizes in practice.
Most blockchains are not archival backends
“On-chain forever” is often false in 2026. EIP-4444 says Ethereum clients should stop serving historical headers, bodies, and receipts older than one year on the peer-to-peer layer, and may locally prune that historical data. On July 8, 2025, the Ethereum Foundation announced that all Ethereum execution clients support partial history expiry, with typical node disk savings of 300-500 GB from removing pre-Merge block data.
EIP-4844 is even clearer that data availability is not archival permanence. Blob data is fully downloaded by consensus nodes, but the EIP says it can be deleted after a relatively short delay, with the chosen minimum retention around 18 days. That is a valid design for rollup data availability. It is not a permanent storage guarantee.
The practical implication is simple. If an application stores critical media, legal records, governance artifacts, or token-economy state assumptions in a layer whose standard nodes are designed to prune history, then the application is outsourcing permanence to someone else. That “someone else” is usually a specialist archive, a pinning vendor, an indexer, or a foundation-run service. The decentralization risk is not just that data might disappear. It is that a smaller set of operators becomes structurally indispensable.
Law and moderation reintroduce discretion
Immutable replication collides with legal obligations. Article 17 of the GDPR grants a right to erasure in defined circumstances, including cases where personal data are no longer necessary, consent is withdrawn, or processing was unlawful. A storage network that markets itself as incapable of deletion is not exempt from the jurisdictions in which miners, gateways, and service operators actually live.
Arweave’s public docs acknowledge this tension directly. The mining guides warn operators to understand the legal implications of storing Arweave data, and the blacklist docs tell miners to use content policies to avoid material that may be illegal in their jurisdiction. The protocol docs then frame content policy as voluntarist and layered, with each participant able to choose what data they store and serve, plus optional blacklist feeds.
The structural result is important. Legal pressure does not necessarily delete data everywhere, but it can fragment replication and access by geography, operator policy, and gateway behavior. That is an inference from the design, not a protocol bug. A network can remain decentralized at consensus while becoming unevenly available across jurisdictions because operators rationally protect themselves.
Governance choke points matter more than branding
Permanent storage claims should be evaluated by authority dispersion, not by slogans. Filecoin Plus is a useful case study because the docs are unusually explicit about the governance path. Root-key holders grant DataCap batches to allocators, a majority of multisig signers is needed to grant or remove an allocator, and allocators decide which clients and use cases qualify for verified status. That is not cosmetic governance. It is an authority layer sitting directly on top of storage demand.
The incentive effect is large. Filecoin says verified deals receive a 10x quality adjustment multiplier, and verified data raises a provider’s quality-adjusted power and block-winning probability. From a decentralization-purist lens, that means the protocol’s most attractive storage demand can be steered by a governance-mediated credentialing system. The model may be justified. But it is not neutral, and it should be analyzed as such.
Arweave shows a different kind of coordination pressure. Its docs say new nodes bootstrap through trusted peers, and note that the Digital History Association operates peer pools such as peers.arweave.xyz. The same docs also say nodes validate received data, so abuse potential is limited. That is the right balance to state: bootstrap trust is not equivalent to full control, but it is still a coordination surface that matters when measuring structural decentralization.
IPFS exposes the same pattern at the gateway layer. If users identify content by a gateway URL rather than by the content identifier, then a single gateway outage or compromise can make decentralized content appear deleted, disabled, or suspect. A protocol does not become meaningfully decentralized just because the base layer is peer-to-peer. If access, verification, or demand qualification concentrates, the effective system recentralizes around those choke points.
What a credible permanence claim should prove
A credible permanence claim should disclose six things up front.
- Who pays after upload. If storage is term-based, the renewal agent and renewal budget should be explicit.
- What the proof actually proves. Access, replication, continuous sealing, and low-latency retrieval are not the same thing.
- Which governance actors can redirect demand. If allocators, multisigs, foundations, or curated gateway sets matter, say so.
- How many independent access paths exist. Permanent bytes behind a single popular gateway are not operationally permanent.
- How legal conflict is handled. Jurisdictional filtering and voluntary blacklists should be treated as part of the system design.
- How long-term usability is preserved. The Library of Congress notes that bit-level preservation alone does not ensure future usability, especially when formats, codecs, software, or hardware become obsolete.
The last point is underrated in Web3. A network may preserve bytes perfectly and still fail archival use if future users cannot render the file, decode the asset, or reconstruct the application context needed to interpret it. “Permanent” should therefore mean preserved, retrievable, interpretable, and legally serviceable across time. Anything less is a narrower claim dressed up as forever.
For token economy design, this matters immediately. A storage token is not only paying for capacity. It is underwriting retrieval operations, governance power, legal handling, and long-tail archival obligations. At FinDaS Tokenomics, we treat permanence claims as balance-sheet promises inside the token economy, not as branding copy. For teams doing tokenomics consulting around storage-backed protocols, the right question is never “is it decentralized storage?” The right question is “which actors, thresholds, and budgets keep this data usable when the easy years are over?”
