Cover photo

Blobscan: The Cost of Archiving Ethereum’s Blob Data

The infrastructure costs, scaling challenges, and community efforts behind preserving Ethereum’s blob data.

Navigating Sustainability in the Current Crypto Landscape

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.

Increasing Storage Demands After Ethereum Upgrades

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
(EIP-4844)

3 - 6

March 13, 2024

Pectra
(EIP-7691)

6 - 9

May 7, 2025

Fusaka
(PeerDAS)

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.

From Unpredictable Cloud Costs to Infrastructure Stability

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.

Transparent Breakdown of Our Monthly Costs

To give a clear picture of our monthly expenses:

Service

Approximate USD per month

DigitalOcean Kubernetes
(5 Blobscan instances)

$400

Google Cloud Storage
(data storage and egress)

$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.

Decentralizing Storage of Blobs

Our Experience with Decentralized Storage: Swarm

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.

Exploring IPFS and Community-Powered Storage

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.

What Comes Next

Reducing Scope to Extend Runway

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.

New Revenue Experiments

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.

A Call to the Community

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.