blobarchive.net

2026-08-01 · Tristan Wilson

A call for the network's first independent writer

BlobArchive just launched and currently has one writer (mine!), which I will endeavour to keep up and running, but this presents a liveness risk for new blobs being added to the archive.

This is an invitation for any technically capable organization or individual to run an independent BlobArchive writer. It would be on your host, using your L1 providers, under your administrative control, with your own signing key, storage, monitoring, and operating responsibility.

Running a writer is permissionless, but I would like to include some extra writer addresses in the default configuration.

If you want to run a writer for a network not currently included, eg a testnet, or a different L2, please go ahead.

What a writer actually does

A writer is the part of the system that decides what belongs in the archive and then says so under its own signature. It runs the Ethereum-facing indexers, follows each L2’s published posting schedule, acquires complete blob bytes, verifies every blob against the KZG commitment in the beacon block, updates the content-addressed heads, applies retention, and signs one publication document that is relayed to the swarm through a read-only public edge.

The current production archive publishes four finalized heads: all, arbitrum-one, robinhood and base, plus one small bounded unfinalized head used for local live views. An independent writer could publish any of those finalized heads. (The unfinalized head is deliberately excluded: it is a mutable snapshot with exactly one authority, and the multi-writer follower support currently works with finalized heads.)

More followers and replicas decentralize storage and serving. Only another writer, deriving the head from its own Ethereum inputs, decentralizes the question of whether the head was complete in the first place and its liveness.

System requierments

Measurements taken from the production writer on 2026-08-01.

How trust actually works here

A follower can follow multiple writers. Each follower operator authorizes writers locally, by name and by pinned public key, in its own configuration. A follower admits a claim only when it is provably compatible with the archive it already serves, and on conflict or incomplete proof it keeps serving its last good generation rather than choosing a winner. There is no majority, no leader election, no shared key, and no global registry of approved writers.

What a second writer buys is availability redundancy plus the ability to compare two independently derived roots at equal coverage and see a disagreement instead of copying it.

The code and the normative multi-writer contract are public: the independent-writer guide and the specification. The architecture is described in how BlobArchive works and the trust boundary in discovery and trust.

Signing up

Public, on GitHub Discussions: https://github.com/blobarchive/bloar/discussions. Start a thread there. A useful first message answers six things:

Operator:        who you are, and whether you are acting for an organization
Region/network:  region, provider, and ASN if you know it
Hardware:        CPU, memory, storage type and capacity, and headroom plan
Experience:      relevant operational experience, especially Ethereum
                 infrastructure, IPFS/libp2p, or long-lived archival storage
Heads:           which finalized heads you would want to publish
Timing:          when you could realistically start, and at what pace

The independent writer FAQ covers all of this in operational detail: bootstrap options, key custody, upgrade compatibility, monitoring, incident expectations, and what each stage actually requires.

If you would rather run a follower first and decide later, that is a sensible order: join the network is where to start, and the documentation covers the rest of the system. Followers are welcome and their participation also strengthens the network.