When developers say they’re “storing files on IPFS,” they’re ingoring a critical detail: IPFS itself doesn’t store anything, and you’re often just using some web2 company’s servers.
IPFS sees a great deal of usage in the web3 storage space. It’s cheap (or free), it generates a deterministic hash per file, and is well-supported by dedicated storage services like Pinata.
IPFS is often lumped together with Filecoin. While Filecoin can be used to persist IPFS data, data is usually stored on a SaaS-like pinning service, and storage on Filecoin has noticeable bottlenecks.
In this article, we’ll demystify what IPFS actually is, its relationship with Filecoin, and how Load S3 offers an alternative with the same persistent ID system, better provenance, cheaper fees, and a true route through to pay-once-store-forever permanence.
Where does my file actually go when I store it on IPFS?
IPFS (InterPlanetary File System) is a protocol for content-addressed data retrieval, not a storage network. When you add a file to IPFS, your local node generates a CID (a hash of the file’s content) and makes that file available to the network.
But here’s the catch: if your node goes offline or garbage collects the file, it disappears from the network unless someone else has it.
This is where devs rely on pinning services. Services like Pinata, Infura, and Web3.Storage are essentially Web2 companies running IPFS nodes on AWS or Google Cloud, promising to keep your content pinned (not garbage collected) for as long as you pay them.
The reality of IPFS pinning services
Traditional pinning services work like any other cloud storage provider except they’re storing IPFS-formatted data. You’re trusting:
- A centralized company to stay in business
- Their infrastructure team to keep servers running
- Their financial health to keep paying cloud bills
- Their terms of service not to change
If the company shuts down or stops paying their cloud bills, your data vanishes. There’s no cryptographic proof they’re actually storing your file, no economic incentive mechanism keeping them honest beyond traditional contracts, and no network-level redundancy built in.
This reality was made clear in April 2025 when nft.storage – an IPFS pinning service – published a request for funding to remain operational:
“We’re seeking donations so that we can continue preserving all NFTs as timeless assets—so that they don’t become ‘dead’ when off-chain storage solutions for linked images and metadata fail.”
This incident (and plenty of others like it) prove that providers need to fall back to infrastructure with clear incentives that make sense over long time horizons.
The Filecoin Promise
Filecoin emerged to solve this by creating a decentralized storage network with economic incentives. Storage providers must post collateral, submit cryptographic proofs (Proof of Replication and Proof of Spacetime) that they’re actually storing your data, and face penalties for failures.
The key benefit: your IPFS CID is preserved. Since Filecoin uses the same content-addressing scheme as IPFS, a file stored on Filecoin remains accessible through IPFS gateways using its original CID. This is powerful because you can move data from a pinning service to Filecoin without breaking any links or changing identifiers.
The Filecoin Reality
But Filecoin has practical drawbacks that often go unmentioned. When you upload a 1 GiB file to Filecoin, you’re looking at:
- Acquiring some $FIL
- 1-2 minutes to propose and fund the storage deal
- 1-5 minutes to upload data to the storage provider
- 30-60 seconds for on-chain deal verification
- 1.5 to 3 hours for sector sealing
Your file is only retrievable after that sealing process completes, because sealed storage is what’s verifiably committed onchain. Some providers offer unsealed data retrievability, but it’s far from instantaneous due to upload latency and finality constraints.
For applications needing fast data availability like real-time feeds, interactive apps, and immediate content serving, this delay makes Filecoin impractical as a primary storage layer. It works well as an archival backstop, but not as hot storage.
A different approach: CIDs vs real cryptographic provenance
Both IPFS and Filecoin use CIDs for content addressing. A CID proves that data hasn’t been tampered with (it’s a cryptographic hash), but it doesn’t prove who created it or when. If someone uploads a file to IPFS with the same content as yours, it produces the same CID. This enables deduplication, but it means CIDs alone don’t establish authorship.
Enter ANS-104 DataItems, the data format used by Arweave’s ecosystem and Load S3. An ANS-104 DataItem is a self-contained, cryptographically signed data container that wraps your content with:
- The data payload itself
- Metadata tags
- The owner’s public key
- A cryptographic signature
DataItems can be signed with Ethereum secp256k1 keys, Solana Ed25519 keys, or Arweave RSA-PSS keys, making them blockchain-agnostic while maintaining cryptographic proof of authenticity. The DataItem ID is derived from the signature, creating a persistent identifier that proves both content integrity and authorship.
This provenance model has practical security benefits. In a traditional S3 bucket, if your access keys leak and someone uploads malicious objects, the data appears “authentic” because it came through valid credentials. With ANS-104 DataItems, you can cryptographically verify who signed each object—even after a bucket compromise, you can distinguish legitimate uploads from malicious ones.
Load S3: S3-compatible storage with Arweave integration
Load S3 takes a different architectural approach than either pinning services or Filecoin. It’s an S3-compatible temporary storage layer that natively stores data as ANS-104 DataItems, with optional one-click migration to Arweave’s permanent storage.
The system works through a marketplace of storage providers running HyperBEAM nodes with custom S3 devices. Unlike Filecoin’s global consensus model, Load S3 storage providers operate independently: no coordination overhead, no sector sealing delays, no network-wide agreement required. You choose which provider to use (or let routing protocols choose based on reputation metrics), and you get immediate data availability.
Here’s what this looks like in practice:
Load S3 is currently run by a handful of storage providers (SPs) with a clear roadmap toward a decentralized network of independent providers coordinated through AO, Arweave’s compute layer. Even in its current federated state, the ANS-104 provenance model provides verification benefits that traditional S3 lacks: you can cryptographically prove the origin and integrity of every stored object.
Storage pricing is marketplace-based, with the anchor rate at $0.015/GB/month. For comparison, storing 1TB for a year costs (excluding egress costs):
The xANS-104 State Transition Model
What makes Load S3 comparable to the relationship between IPFS and Filecoin is the xANS-104 state transition model. Every object stored in Load S3 is an ANS-104 DataItem with three possible lifecycle states:
- tANS-104 (temporal): Stored temporarily in Load S3, served from HyperBEAM LS3 layer
- ∅ANS-104 (void): Explicitly deleted or expired from the LS3 layer
- ∞ANS-104 (permanent): Committed to Arweave for permanent storage
The cryptographic signature remains invariant across all states. When you transition from temporary to permanent storage, the DataItem ID stays the same—no migration complexity, no broken links, just a state change from t to ∞.
This is conceptually similar to the IPFS → Filecoin pipeline where CIDs remain constant, but with a few key differences:
- Immediate availability: No sector sealing delay. Data is retrievable within seconds of upload.
- Cryptographic provenance: ANS-104 signatures prove authorship, not just content integrity.
- True permanence option: Arweave’s pay-once, store-forever model vs. Filecoin’s renewable storage deals.
Arweave’s Permanence Guarantee
When you commit data to Arweave, you pay once (currently ~$11/GB) and it’s stored permanently. Not only for as long as deals are renewed, or for as long as miners find it profitable.
This works through Arweave’s endowment model. Your one-time payment goes into an endowment fund that generates interest over time. As storage costs decrease (following historical trends), the interest covers storage costs perpetually. There are 600+ gateways serving Arweave data, and the network has over 200 miners with economic incentives to maintain copies.
For data that is critical to keep (legal records, research datasets, cultural archives, NFT metadata) this permanence guarantee is fundamentally different from renewable storage deals. You’re not trusting renewal infrastructure or hoping future economics work out. You pay once, and the protocol handles persistence.
Practical Considerations
When Filecoin Makes Sense
- You need temporary decentralized storage with BFT and strong cryptographic proofs
- You’re okay with 2-3 hour delays for data retrievability
- You’re building for storage-first use cases where upfront sealing time isn’t critical
- You need renewable storage deals with specific term structures
- Filecoin foundation slips you a juicy grant
When Load S3 + Arweave Makes Sense
- You need immediate data availability (sub-second, not hours)
- You want S3 API compatibility with minimal migration from web2 workflows
- You need flexible storage terms (temporary hot cache that can optionally become permanent)
- You want cryptographic provenance proving data authorship, not just integrity
- You’re building for EVM ecosystems (Load is EVM-compatible with native Arweave integration)
Load S3 offers something neither pinning services nor Filecoin provide: S3-compatible hot storage with cryptographic provenance and optional one-click permanence upgrades. For teams moving from IPFS pinning services to something more robust, this may be the right balance.
Getting Started
If you’re currently using IPFS pinning services and want to explore alternatives:
- For immediate hot storage: Try Load S3 with the standard S3 SDK, HTTP API, or Arweave’s Turbo SDK. Storage grants up to 100GB/month are available.
- For permanent archives: Consider Arweave directly via Turbo SDK, or use Load S3’s state transition model to upgrade temporal data to permanence.
The key insight: “storing on IPFS” is a misnomer that hides complexity. What you’re really choosing is a storage provider: a centralized pinning service, decentralized Filecoin network, or S3-compatible Load S3 with optional Arweave permanence.
Understanding these distinctions helps you choose the right tool for your use case, rather than defaulting to IPFS without DYOR.
Try Load S3: Get started with up to 100GB/month free storage at load.network/s3-partner-program