You are mistaken if you believe IPFS is decentralized. The protocol is. The maintenance is not. On September 30, Shipyard—the team responsible for Kubo, Helia, Boxo, Rainbow, and the public gateways that most users never see but constantly depend on—announced it would cease operations. Protocol Labs frames this as a transition to a "lighter-weight governance model." That is a euphemism. What actually happened is that the single most important maintenance entity in the IPFS ecosystem ran out of funding, and nobody has stepped in to replace it.
The ledger remembers what the mempool forgets. In this case, the ledger shows a protocol that has been running for years, but the maintenance ledger—the commits, the issue responses, the security patches—is about to go dark.
Context: What Shipyard Actually Did
IPFS, the InterPlanetary File System, is a peer-to-peer hypermedia protocol that uses content addressing to store and share data. It is the backbone of decentralized storage narratives, the underlying layer for NFT metadata, and the foundation upon which Filecoin's incentive structure was built. Shipyard was not a separate company. It was a team of Protocol Labs' most experienced IPFS developers, tasked with maintaining the core implementations: Kubo (the Go client), Helia (the TypeScript implementation), Boxo (the foundational library), and Rainbow (a gateway implementation). They also operated critical public infrastructure—ipfs.io, dweb.link, and the bootstrap nodes that help new peers discover the network.
The protocol itself does not stop running. That is the cold comfort. Distributed hash tables do not require a central kill switch. But "running" and "healthy" are different states. Kubo, the most widely deployed IPFS client, will continue to function until it encounters a bug, a security vulnerability, or a compatibility issue with an upstream dependency. Then it will fail, and there will be no dedicated team to fix it.
Core: The Systematic Teardown
Let me be precise about what breaks. Based on my experience auditing infrastructure projects—and I have spent years dissecting where decentralized systems actually concentrate their risk—the failure mode here is not catastrophic collapse. It is entropy. Technical debt accumulates. Security patches lag. Performance optimizations never land. The codebase ages in public, and the ecosystem pretends not to notice.
The first casualty is the public gateway. ipfs.io and dweb.link are the entry points for users who do not run their own nodes. When those gateways degrade—when they start returning 5xx errors or timing out—the user experience collapses. Developers who depend on these gateways for NFT metadata or application data will be forced to run their own infrastructure. That is a cost increase, and in a bear market, cost increases drive abandonment. I have seen this pattern before: in 2019, when a major Ethereum gateway provider cut its free tier, the projects that depended on it either paid up or died. The same calculus applies here, except the exit is not a pricing change. It is a slow, unannounced decay.
The second casualty is security. Kubo is a complex piece of software. It has had vulnerabilities before. Every major IPFS implementation has. The difference is that previously, there was a funded team whose job was to find and fix these issues. Now there is a governance model that has not yet demonstrated it can organize individual maintainers effectively. The window between a vulnerability being disclosed and a patch being deployed will widen. That is not speculation. That is the mathematical consequence of removing dedicated labor from a system. In my 2017 audit of a Sydney-based ICO's smart contract architecture, I identified fourteen distinct edge cases where funds could be drained. The founders ignored my report and shipped anyway. The lesson I took from that experience was simple: security is not a feature, it is a maintenance discipline. And maintenance discipline requires funded, accountable humans.
The third casualty is the roadmap. IPFS was not standing still. There were ongoing efforts to improve performance, reduce memory usage, and enhance the gateway experience. Those efforts now have no clear owner. Protocol Labs' shift to a "lighter-weight governance model" means technical decisions will be made by individuals, not a coordinated team. Individual maintainers are capable, but they are also intermittent. They have other jobs. They have other priorities. The consistency that a funded team provides—the daily commits, the triaged issues, the release cycles—cannot be replicated by volunteer effort alone. I have watched this dynamic play out across dozens of open-source projects. The ones that thrive have either a corporate sponsor or a critical mass of paid contributors. The ones that do not, decay.
Here is the uncomfortable truth that this event exposes: IPFS's decentralization was always a protocol-level property, not an organizational one. The network is distributed. The maintenance was not. A single entity—Protocol Labs, through Shipyard—controlled the core implementations, the public gateways, and the bootstrap infrastructure. When that entity withdrew, the fragility of the entire system became visible. Code is not law, it is merely preference. And the preference of a single funder can change the trajectory of an entire ecosystem.
The downstream impact is real. NFT projects store metadata on IPFS. GameFi applications use it for asset storage. Filecoin's storage providers depend on the IPFS toolchain. None of these will break tomorrow. But the risk profile has shifted. The illusion persists until the liquidity dries—and in this case, the liquidity that dried was not capital, but maintenance capacity.
Contrarian: What the Bulls Got Right
Now let me address what the bulls got right, because they are not entirely wrong.
The transition to a lighter governance model could, in theory, be the healthiest thing that has happened to IPFS in years. The dependency on Protocol Labs was always a single point of failure. A foundation-funded, community-driven maintenance model, if executed properly, could distribute responsibility across a wider set of contributors. It could reduce the influence of any single corporate entity. It could attract developers who were previously excluded from the decision-making process.
There is also a precedent for this working. Open-source projects like Linux and PostgreSQL have thrived under distributed governance models. The key difference is that those projects have large, diverse contributor bases built up over decades. IPFS has a smaller pool of qualified maintainers, and the most experienced ones just left. The question is not whether community governance can work in principle. It is whether it can work here, with this codebase, with this contributor pool, and with this timeline.
The bulls also correctly note that IPFS is not the only decentralized storage option. Arweave and Storj are positioned to capture any users who lose confidence in IPFS's maintenance trajectory. Competition is healthy. If IPFS's governance transition fails, the market will reallocate. That is the mechanism working as intended.
Takeaway: What to Watch
The signals to watch are concrete. GitHub commit frequency on Kubo and Helia. Response times on critical issues. The availability of ipfs.io and dweb.link. Whether the IPFS Foundation announces a funded maintenance program, or whether it expects volunteers to carry the load. Filecoin's relative price performance against Bitcoin and Ethereum will also tell you whether the market believes the ecosystem is degrading.
Immutability is a feature, not a virtue. The IPFS protocol will persist. But persistence without maintenance is just abandonment with better marketing. The question is not whether IPFS survives. It is whether the people who depend on it understand what they are depending on—and whether they are prepared for the answer.