IPFS (InterPlanetary File System)

What Is IPFS?

IPFS (InterPlanetary File System) is a peer-to-peer protocol designed to make the web more decentralized, resilient, and efficient. Instead of fetching a file from a specific server using a URL like https://example.com/image.png, IPFS lets you request a file by its content hash: a unique fingerprint derived from the file's actual data. Any node on the network that has a copy of the file can serve it, and you can verify the data is correct by recomputing the hash yourself.

The protocol was created by Juan Benet and Protocol Labs, with the first specification published in 2015. IPFS draws on ideas from earlier peer-to-peer systems like BitTorrent and distributed data structures like Merkle trees, combining them into a general-purpose content-addressed storage layer. As of 2026, the public IPFS network includes over 250,000 nodes and handles hundreds of millions of gateway requests per week.

How It Works

IPFS replaces location-based addressing with content addressing. Rather than asking "which server has this file?" you ask "who has the file with this hash?" This shift has several consequences for how data is stored, retrieved, and verified.

Content Identifiers (CIDs)

Every piece of data on IPFS gets a Content Identifier, or CID. A CID is generated by hashing the file's data using a cryptographic hash function (SHA-256 by default) and encoding the result alongside metadata about the hash algorithm and codec used. The CID format uses multiformats, making it self-describing: any client can determine how to decode and verify the data from the CID alone.

Because the CID is derived from the content, changing even a single byte produces an entirely different identifier. This property guarantees data integrity: if you request a CID and receive data that hashes to that CID, you know the data has not been tampered with.

# Example: adding a file to IPFS and getting its CID
$ echo "Hello, IPFS" | ipfs add
added QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN -

# The CID (Qm...) is a Base58-encoded multihash
# Anyone with this CID can retrieve the exact same data
$ ipfs cat QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
Hello, IPFS

Chunking and Merkle DAGs

Large files are split into smaller blocks (typically 256 KB each). Each block gets its own CID, and the blocks are organized into a Merkle Directed Acyclic Graph (Merkle DAG). The root CID of this DAG represents the entire file. This structure enables parallel downloads from multiple peers, deduplication of identical blocks across files, and efficient verification using Merkle proofs.

IPFS uses a data format called UnixFS to represent files and directories within the Merkle DAG. UnixFS handles the mapping between the block-level DAG structure and familiar filesystem concepts like filenames, directories, and file metadata.

Peer Discovery and Retrieval

When a node wants to retrieve content by its CID, it follows these steps:

1. The node checks its own local datastore. If the content is cached locally, retrieval is instant.
2. If not found locally, the node queries the Distributed Hash Table (DHT), a Kademlia-based routing system where nodes advertise which CIDs they store.
3. The DHT returns a list of provider nodes that have the requested content.
4. The requesting node connects to one or more providers using libp2p (which supports TCP, QUIC, WebSockets, and WebRTC) and downloads the blocks.
5. Each received block is verified by recomputing its hash and comparing it to the expected CID.

IPNS: Mutable Naming

Because content addressing means any change to a file produces a new CID, IPFS provides the InterPlanetary Name System (IPNS). IPNS creates a mutable pointer (tied to a cryptographic key pair) that can be updated to reference different CIDs over time. This is analogous to a domain name that can point to different IP addresses: the IPNS name stays the same while the underlying content changes.

The Pinning Model

A common misconception about IPFS is that uploading a file makes it permanently available. In reality, IPFS nodes only keep data they are actively using or have explicitly marked for retention through a process called pinning. Unpinned data is eventually removed through garbage collection to free up disk space.

This means content persistence on IPFS requires at least one node to pin the data. For individual users running their own nodes, this means keeping the node online. For applications that need reliable availability, pinning services provide always-on infrastructure.

Pinning Services

Several commercial services offer IPFS pinning, ensuring content remains available even when the original uploader goes offline:

• Pinata: a developer-focused platform with APIs and SDKs designed for NFT marketplaces and dApp frontends
• Filebase: an S3-compatible gateway that offers geo-redundant pinning across multiple storage networks
• NFT.Storage: a service specifically designed for NFT metadata, pinning data to both IPFS and the Filecoin network for long-term persistence

These services standardize around the IPFS Pinning Service API, which allows applications to manage pins programmatically. The tradeoff is that relying on a single pinning provider reintroduces some centralization, which is why critical applications often pin to multiple providers simultaneously.

IPFS vs. Arweave vs. Traditional CDNs

Understanding where IPFS fits requires comparing it with other storage approaches:

IPFS excels when you need verifiable, content-addressed data with flexible storage economics. Arweave is better when permanence is non-negotiable (legal archives, historical records). Traditional CDNs remain superior for latency-sensitive applications where censorship resistance is not a requirement.

Use Cases in Crypto

NFT Metadata Storage

When an NFT is minted, the on-chain smart contract typically stores only a URI pointing to the token's metadata (name, description, image). If that URI points to a centralized server, the NFT's content can be altered or deleted by the server operator. IPFS solves this: storing metadata on IPFS means the CID in the contract cryptographically guarantees the metadata's integrity. Major platforms including OpenSea, Rarible, and Zora support IPFS-hosted metadata, and over 115 million NFTs reference IPFS CIDs for their assets.

Censorship-Resistant DeFi Frontends

DeFi protocols like Uniswap, Aave, and Curve host their web frontends on IPFS. Even if a domain registrar or hosting provider takes down the primary website, users can access the frontend through any IPFS gateway or by resolving the CID directly. This separation between the on-chain protocol (which cannot be censored) and the off-chain frontend (which traditionally could be) is a critical resilience measure for decentralized applications.

ENS Content Resolution

The Ethereum Name Service allows users to set a contenthash record on their ENS name that points to an IPFS CID. When someone navigates to yourname.eth using an ENS-aware browser (like Brave or MetaMask's built-in browser), the browser resolves the ENS name, retrieves the contenthash, and loads the site from IPFS. This creates a fully decentralized website: the name is on Ethereum, the content is on IPFS, and no single server can take it down.

DAO Document Storage

DAOs use IPFS to store governance proposals, voting records, and organizational documents. Snapshot, a widely used off-chain governance platform, stores vote data on IPFS. Because the CID verifies integrity, anyone can independently confirm that governance records have not been altered after the fact.

Smart Contract Metadata

The Solidity compiler embeds IPFS CIDs in compiled smart contract bytecode, pointing to the contract's source code metadata. Verification services like Sourcify use these CIDs to match deployed bytecode with its original source, enabling trustless contract verification on the blockchain.

Risks and Considerations

Data Availability Is Not Guaranteed

IPFS does not guarantee that content remains available. If every node storing a CID goes offline or garbage-collects that data, the content becomes unretrievable even though the CID still exists. For applications where data loss is unacceptable, pinning strategies and redundancy across multiple providers are essential.

Gateway Centralization

Most users access IPFS content through HTTP gateways like ipfs.io or dweb.link rather than running their own node. These gateways are operated by a small number of organizations, creating potential censorship chokepoints and single points of failure that undermine the protocol's decentralization goals.

Performance Variability

Content retrieval speed on IPFS depends on factors like how many peers store the data, their geographic distribution, and network conditions. First-time retrieval of rarely-accessed content can be significantly slower than a traditional CDN. Caching and popular content benefit from the network effect (more nodes store and serve popular CIDs), but long-tail content can suffer from high latency.

Immutability Tradeoffs

Content addressing means that once illegal, harmful, or private data is uploaded and its CID is known, it cannot be "deleted" from the network: any node operator can choose to pin it. While individual gateway operators can blocklist specific CIDs, the underlying peer-to-peer network has no global content removal mechanism.

Pinning Costs

Unlike Arweave's one-time payment model, IPFS pinning requires ongoing fees. For projects storing large datasets or high volumes of NFT metadata, these costs can accumulate. The economics of pinning also mean that if a project runs out of funding or a pinning service shuts down, content availability is at risk unless migrated to another provider.

Why It Matters

IPFS has become foundational infrastructure for the crypto ecosystem. It provides the off-chain data layer that complements on-chain logic: NFTs need somewhere to store their images, DeFi protocols need censorship-resistant frontends, and DAOs need tamper-proof document archives. Without content-addressed storage, many of the guarantees that decentralized applications promise would break down at the data layer.

For Bitcoin-native applications, the concept of content addressing aligns with the same verification principles that underpin the UTXO model: don't trust, verify. Just as a Bitcoin node validates every transaction against consensus rules, an IPFS client verifies every block against its CID. For a deeper look at how decentralized data infrastructure intersects with blockchain applications, see our research on decentralized physical infrastructure networks.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.