Protocol Labs Tech Stack Explained: IPFS, Filecoin and libp2p

Protocol Labs is an open-source research and development lab. It was founded in 2014 and is best known for creating IPFS, the InterPlanetary File System, and Filecoin, a storage network with its own token, FIL. The lab also builds libp2p, a modular networking library that handles how computers find each other and exchange data.

The lab describes its work as building protocols, tools and services for a more open internet. In practice, this means writing specifications, maintaining reference implementations and supporting developers who build on those tools. Many other teams and independent contributors also work on the same code, so the lab is one important group in a wider ecosystem rather than the only owner of it.

When people search for Protocol Labs, they usually want to know what the lab makes and how the pieces relate. The short answer is that it builds a stack of layers. Networking sits at the bottom, content addressing and file transfer sit on top of it, and an incentive layer for storage sits above that. Each layer can be studied on its own, which is useful when you only need one part of the stack.

It also helps to separate the lab from the products. A research lab can release a protocol, but the people who run nodes, store data or build applications decide how that protocol is used. Keeping that distinction in mind makes it easier to judge claims you read about the stack.

The stack has three main parts that are often mentioned together.

• libp2p is a modular networking stack. It provides peer identities, transports, peer discovery and message routing, so applications do not have to rebuild those functions from scratch.
• IPFS is a content-addressed protocol for storing, finding and transferring files and other data. It sits on top of libp2p.
• Filecoin is a blockchain-based network that pays storage providers to keep data for defined periods. It uses IPFS-style content identifiers and adds an economic and proof layer.

These parts are related but separable. You can run an IPFS node without using Filecoin, and libp2p is used by projects outside the IPFS family. Filecoin depends on the content addressing model from IPFS, and both depend on libp2p for communication between nodes.

A simple way to think about it is to start at the bottom. libp2p answers how nodes talk. IPFS answers how data is named and fetched. Filecoin answers who gets paid to keep the data available and how anyone can check that they did.

IPFS does not locate files by where they live on a server. Instead, a file or block of data is hashed, and the hash becomes its content identifier, usually called a CID. If the content changes, the CID changes. This is called content addressing, and it means a CID points to exactly one set of bytes.

That design has practical effects. A requester can verify that the data it received matches the identifier, so it does not need to trust the node that sent it. The same content can be served by many nodes, which can make transfers more resilient when one source is offline.

CIDs can be version 0 or version 1, and version 1 adds details such as the encoding used. Newer CIDs can also point to directories and structured data. The exact format details are in the official IPFS specifications, which are the right place to check the current defaults.

For readers, the main point is that a CID is a fingerprint of content. It is not a link to a location and it does not say who is hosting the file. Hosting is a separate question that depends on which nodes have pinned or cached the data.

To retrieve content, an IPFS client asks the network who has a given CID. Peers and content routers help answer that request, often using a distributed hash table, and then the client fetches the blocks from one or more nodes. Blocks are checked against their hashes as they arrive.

Retrieval works only while someone holds the data. A node caches content it has recently fetched, but caches are not guaranteed to last. If the holders go offline or delete the blocks, the CID can still exist but the data cannot be found.

Pinning is the standard way to keep content available. A pinned node tells its local storage to keep specific blocks, and the owner of that node decides when to remove them. Many people run a node themselves, while others use a pinning service. Each option has trade-offs in cost, control and trust in the operator.

If you publish content on IPFS, check it from a different network after a day or two. Confirm that the CID resolves, and keep a backup copy of the original file. Treat IPFS as a way to distribute content, not as a permanent archive unless you have arranged storage that is independently maintained.

IPFS by itself does not pay anyone to store data. Filecoin adds that missing piece. Storage clients make deals with storage providers, who commit to keep data for an agreed term and are paid in FIL. The network records these deals on a blockchain so that the terms and payments can be verified by anyone.

The chain is a coordination layer. It tracks which providers have made which commitments, handles payments and records penalties or slashing when a provider fails to meet its obligations. Storage itself happens off-chain between the client and the provider, with the chain holding the record of the agreement.

Filecoin has been running as a live network since its mainnet launch in 2020. Its design choices, including the use of a token for payment and collateral, are documented in its protocol specifications. The details of pricing, collateral requirements and penalty rules can change through network upgrades, so check the current specification rather than relying on older summaries.

For a reader, the key idea is that Filecoin turns storage into a market with rules. Clients pay for a term, providers post collateral, and the protocol tries to make broken promises visible and costly.

Filecoin relies on cryptographic proofs to check that providers really store the data they agreed to keep. The two main proof types are commonly described as Proof of Replication and Proof of Spacetime.

Proof of Replication shows that a provider has stored a unique physical copy of the data. Without this check, a provider could claim to store one copy while actually storing it once and presenting it as many, or could fetch the data on demand from elsewhere. The sealing process that creates the replica is computationally heavy by design.

Proof of Spacetime shows that the provider continues to hold the data over time. The network asks for proofs at intervals, so a provider that drops the data cannot keep passing the checks.

These proofs are the reason Filecoin can offer more than a simple promise. They are also one of the more technical parts of the stack, and their parameters have been refined over time. If you need exact figures for proof timing, hardware requirements or sealing costs, consult the current Filecoin documentation, since those values can change between network versions.

Filecoin separates the act of storing from the act of retrieving. Storage deals establish that a provider has the data. Retrieval is a separate market in which clients pay providers to send that data when needed. A deal and a retrieval can involve different parties, and retrieval terms are not always the same as storage terms.

This split is one reason that a successful storage deal does not guarantee fast access. Retrieval speed depends on the provider's setup, the network path and whether the data is cached or sealed in a way that makes access slower. Clients who need quick access often use a retrieval service or keep a local copy.

Filecoin also supports programmable behavior through its virtual machine, the Filecoin Virtual Machine, which lets developers write smart contracts that interact with storage and payments. The FVM is designed to make Filecoin's on-chain logic accessible to developers who already know Ethereum-style tooling.

If you are building on the network, read the current retrieval and deal documentation first. Confirm the terms with the provider, test retrieval from a clean environment, and avoid assuming that a deal made on one network version behaves identically on another.

Protocol Labs remains an active lab, but the picture of IPFS and Filecoin has shifted over the years. Some commentators have argued that IPFS development slowed when much of the lab's focus moved to Filecoin. Others point to the continued maintenance of IPFS, libp2p and the Filecoin implementations as evidence of ongoing work. Online discussion is not an authoritative source, so use it as a prompt to look at primary records.

The most reliable checks are the project's public repositories, release notes, specification pages and official blog. Look at when each implementation was last released, how many contributors are active, and whether breaking changes are documented. Those signals are more useful than general commentary.

For evergreen research, separate three questions. First, is the protocol still maintained? Second, is the network it supports still running? Third, is the specific feature you care about documented and supported? A project can answer yes to the first two and no to the third.

When you cite the stack in your own work, write down the date and version you checked. The protocols change, and an accurate description in one year may need revision in the next.

Using IPFS or Filecoin is not difficult, but it rewards caution. Start with a small test before storing anything important.

1. Decide what you need. Is it content distribution, long-term archiving, or on-chain storage that smart contracts can reference? Each goal leads to a different setup.
2. Run a local IPFS node or use a reputable hosted service. Pin the content you care about and confirm that you can retrieve it from another machine.
3. Keep an independent copy of the original file. Do not rely on a single node or provider for the only copy.
4. If you use Filecoin deals, read the provider's terms, the length of the deal, the retrieval conditions and what happens at expiry.
5. Store the CIDs and deal records somewhere safe, and record the date and software version you used.

Security matters as well. Be wary of unsolicited offers to store or pin your files, and never share wallet seed phrases or private keys when setting up tools. Verify software from official sources before installing it. Any site or message that asks for your keys is a warning sign, whatever its branding.

Finally, remember that storing public content on IPFS makes it reachable by anyone who has the CID. Do not publish private or sensitive data without encrypting it first.