An IPFS based Ethereum blob archive you can run locally

Keep Ethereum blobs local

Run a follower for every historical blob, or just the blobs your L2 node needs. Use your own local endpoint instead of a hosted third-party API.

Join the network How it works

Choose your scopeAll history or one L2
Verify locallyNo hosted API dependency
Decentralize the archiveRetain and serve a replica

v0.1.0 — first release. This is the first release and the network has only one writer at the moment, so writer outage is a liveness risk (ie publication of new blobs may stall, old ones would still be available). It is a priority to find more operators willing to be writers.

The network should provide good coverage for historical mainnet blobs even in the event of writer outage, which would be useful if you are trying to sync an L2 from genesis, for example.

The live head should not be relied on if you need near real-time blobs, we've currently measured that the live head changes propagate in about 1-2 minutes. Use a separate consensus node for now if you need truly live blobs, with bloar only for historical blobs.

We have tested this in lab conditions but as this is the first release there will likely be issues, please report any you find through GitHub issues.

Why complete blob history needs a network

Rollups publish their data to Ethereum as blobs. Blobs were always intended to be temporary on Ethereum: consensus nodes prune them after 4096 epochs, about 18 days. After that, in theory, it is up to parties economically interested in the blobs (eg L2s, node providers) to preserve them, but they are not always easily available to everyonne.

Since Fusaka, retrieval changed shape too. PeerDAS made ordinary nodes lighter: each one custodies a sampled subset of every blob's erasure-coded columns rather than whole blobs, so an ordinary beacon node may not serve a complete blob response even inside the custody window. Reconstructing a complete blob means gathering at least half of its columns from across the network (clients document this as a deliberate, opt-in role). That was the right trade since it made the base network got cheaper to run, but it means complete retrieval became a specialized job: once for reconstruction inside the window, and again for everything older than it.

Acquire once, verify and replicate everywhere

BlobArchive does that specialized job once and shares the result. The network's writers acquire complete blobs, verify every one against its KZG commitment, and sign replay-protected head documents. A separate public edge can publish and serve those already-authenticated bytes without holding the signing key or archive mutation authority.

Anyone can then run a follower or attach a Kubo replica and get a local, verified beacon-compatible blobs endpoint. It provides full blob history, from Dencun to the current tip, on their own machine.

BlobArchive decentralizes publication, storage, and serving without pretending trust disappears. Anyone may publish, anyone may replicate, and every follower chooses which writer to trust. blobarchive.net provides curated discovery of writers for convenience.

There is no hosted API

This site serves no blobs. Using the archive means running a node, be that a follower or a replica, and every node that joins is one more independent, verified copy of the history. The join page covers both paths.

From the blog

2026-08-01 A call for the network's first independent writer BlobArchive currently has one writer. We are looking for one technically capable organization or individual to run a second one on their own hardware. 2026-08-01 Fusaka made ordinary nodes lighter and complete blob retrieval harder PeerDAS lets ordinary Ethereum nodes stop downloading every blob. That is good for Ethereum, but it turns complete acquisition into a heavier, deliberate role for L2s and archives.

All posts