The current economic environment in the Ethereum ecosystem and the broader crypto landscape has pushed many projects to rethink how they sustain themselves.
With grants and external funding becoming scarcer—a trajectory also advocated by Vitalik Buterin—public goods projects like Blobscan must now explore sustainable business models beyond traditional grant funding.
As Ethereum continues to scale its data availability layer, the infrastructure required to archive and serve blob data is also growing.
One of Blobscan's missions is to archive blobs and provide access to the data indefinitely.
Blobscan preserves blob data beyond the typical retention window used by Ethereum nodes, enabling long-term research, verification, and historical analysis of Ethereum’s data availability layer.
However, recent Ethereum network upgrades now allow more blobs per block, which naturally increases storage costs for us. Until last year, we were using Google Cloud for both storage and compute. While it served us well, it came with unpredictable costs due to spikes in usage.
Below is a simplified overview of blob target and maximum values across upgrades that expanded blob capacity:
Network Upgrade | Blob Target - Blob Max | Mainnet activation date |
|---|---|---|
Dencun | 3 - 6 | March 13, 2024 |
Pectra | 6 - 9 | May 7, 2025 |
Fusaka | 6 - 9 | December 3, 2025 |
Fusaka (BPO1) | 10 - 15 | December 9, 2025 |
Fusaka (BPO2) | 14 - 21 | January 7, 2026 |
At the current configuration on Ethereum mainnet, we are seeing approximately 30,000–35,000 blobs per day, which corresponds to roughly 3.8–4.5 GB of data per day—over 100 GB of new data every month that Blobscan archives for long-term availability.
This represents a significant and continuously growing dataset that remains accessible over time.
With Fusaka’s BPO2 parameters, daily blob throughput could increase significantly. Under sustained target conditions, this would translate to approximately:
~12.9 GB per day at target
~19.4 GB per day at max capacity
For an archival service like Blobscan, this represents a multiple increase in long-term storage requirements. Every protocol-level increase in blob capacity compounds our infrastructure costs over time.
For this reason, last year we migrated our infrastructure from Google Cloud virtual machines to a DigitalOcean Kubernetes cluster.
Since then, our costs have decreased and become much more stable and predictable. This migration significantly reduced infrastructure volatility.
We also made important API improvements:
Added rate limits
Disabled direct blob downloads
Previously, direct downloads caused double egress charges due to a design oversight. This effectively doubled some of our bandwidth costs. Fixing this had a meaningful financial impact.
To give a clear picture of our monthly expenses:
Service | Approximate USD per month |
DigitalOcean Kubernetes | $400 |
Google Cloud Storage | $250–$400 |
Sentry | $30 |
Grafana Cloud | $100 |
Quicknode | $49 |
This brings our total monthly operational costs to approximately $1000, depending on usage patterns.
It is important to note that this amount only covers infrastructure costs. It does not include any development, maintenance, or operational work on the project itself. At the moment, the funds we have remaining are reserved exclusively for keeping the servers running.
At our current burn rate, we have roughly seven months of runway to continue operating under the existing structure.
We experimented with decentralized storage using Swarm. Our collaboration worked for some time, but our upload rate requirements were higher than what a single Swarm bee node could sustainably handle.
We want to emphasize that we maintain a positive relationship with the Swarm team and do not place any blame. In fact, we are aware that the Swarm team is actively working on a new solution to handle higher upload rates, which is promising for future collaborations.
To ensure long-term sustainability, we are exploring hosting blob data on IPFS using our own dedicated hardware.
Instead of Blobscan bearing the full archival burden alone, IPFS could allow the Ethereum community to participate in preserving blob data.
This approach would allow the community to:
Run IPFS nodes
Pin our IPLD blob data
Distribute storage responsibility
Increase resilience and decentralization
By distributing storage responsibilities, even a small number of community-run nodes can help ensure Blobscan’s resilience and long-term sustainability.
We believe this could transform Blobscan from a centrally hosted service into a truly distributed public infrastructure.
To further reduce operational costs, we are considering sunsetting support for the Hoodi and Sepolia testnets.
Currently, we operate five Blobscan instances: staging, Ethereum mainnet, Sepolia, Hoodi, and Gnosis. However, only the Ethereum mainnet instance has meaningful, sustained usage. The remaining instances generate infrastructure and maintenance costs without comparable community activity.
Focusing our resources on the Ethereum mainnet instance would allow us to reduce operational overhead while preserving the part of Blobscan that provides the most value today.
These are pragmatic decisions aimed at focusing resources where they have the greatest impact for users while extending the project’s sustainability.
If there is strong community interest—or if someone offers infrastructure support such as an IPFS cluster—we would gladly explore maintaining these additional networks in a more sustainable way.
In the coming months, we plan to introduce:
API subscription plans
Ads and sponsorship opportunities
These initiatives are part of our effort to build a sustainable model while keeping Blobscan accessible to the broader Ethereum community.
We will experiment carefully, aiming to strike a balance between sustainability and preserving Blobscan’s public good ethos.
Blobscan was built as public infrastructure for Ethereum.
Today, the ecosystem is evolving. Grants are fewer. Costs are growing. Sustainability is no longer optional—it is necessary.
We are committed to adapting responsibly and transparently. But we cannot do it alone.
Even a small number of community-run nodes pinning blob data could significantly reduce the long-term infrastructure burden on Blobscan.
If you are:
Interested in running an IPFS node
Able to provide storage infrastructure
Interested in sponsoring or partnering
A builder who depends on Blobscan
We invite you to reach out:
📩 Email: contact@blobscan.com
💬 Discord: https://blobscan.com/discord
Together, we can ensure that Blobscan remains resilient, decentralized, and sustainable for the long term.


