Introduction

On Tuesday, November 18, 2025, the FilOz and FilBeam teams were getting ready for the big announcement at the De:PIN day in Buenos Aires. As we were setting up the booth to let visitors take a selfie and pin it via IPFS to Filecoin Onchain Cloud, we discovered that Cloudflare went down, and the demo web app hosted on Cloudflare no longer works. Fortunately, the app was designed in a way that made it easy to move it to a different website hosting service (eth.limo).

The storage layer was running on Filecoin Onchain Cloud, which was already a decentralised platform with no single point of failure. We were able to quickly switch website hosting providers and restore the demo before the first attendees arrived.

In contrast, FilBeam is tightly coupled with the Cloudflare platform. Our early adopters didn’t have any other choice but to wait until Cloudflare restored its service and FilBeam became operational again.

We need to do better.

How can we build a more resilient world where an outage of any large provider, like Cloudflare or AWS, does not bring down half of the internet?

The first idea that comes to many minds is to build the retrieval layer as a decentralised network of nodes operated by independent entities, so that no node is a single point of failure. There are two problems making such a design infeasible:

Most retrieval clients are “dumb” - they need a single URL, a single location from which to obtain the content. Solutions like anycast allow us to push the control plane down to the internet routing level, avoiding a single point of failure. However, to enable HTTPS retrievals, every retrieval node must have a valid TLS certificate for the same domain name. This is a dangerous proposition when the nodes are not trusted and can be operated by adversaries.
It was proven that a fair exchange is impossible without a trusted party [1]. With a decentralised network of retrieval nodes, we have to trust each retrieval node to act honestly and provide a good retrieval service. That is not realistic, as we painfully learned while building Saturn, the decentralised CDN for Filecoin (docs).

We believe that retrieval infrastructure needs a different model, one that’s closer to how the storage infrastructure works in Filecoin: A market of service providers allowing clients to choose the provider that matches their needs and their budget.

In such a world, FilBeam on Cloudflare will be one of many available options. When FilBeam goes down, clients can easily switch to a different retrieval provider, similarly to how web2 sites can switch between different CDNs. Because the data is content-addressed and stored on Filecoin Onchain Cloud, the migration to a different retrieval provider should be seamless. Other networks like Storj, Arweave and Walrus already use a similar model, where the clients must trust the retrieval gateway they interact with, but there are many such gateways available.

We wrote this document to share our knowledge about building a retrieval provider for the Filecoin Onchain Cloud and inspire other teams to create and run alternate retrieval providers.

What is FilBeam (and What It’s Not)

Before we jump into technical details, it’s important to understand that FilBeam’s first and foremost goal is an incentivised retrieval layer that pays Storage Providers for their retrieval services.

Everything else comes second, as support for the main goal: