Is Swarm write-once storage? How long are records kept?

Swarm, the decentralised storage network, keeps each record at an address computed from its content, so a stored record cannot be changed in place. Records are kept while their postage stamp is funded; when the stamp runs out, nodes may remove them.

Updated Datafund 9 min read

Yes, in one precise sense: on Swarm, the decentralised storage network (ethswarm.org), a stored record lives at an address computed from its own content, so it cannot be changed in place; an edited version gets a new address and the original stays where it was. Records are not kept forever. They are kept while the postage stamp that paid for them still has balance, and once it runs out, the nodes holding them are no longer paid to keep them and may remove them.

So the accurate label is write once, read many (WORM), with an expiry you set by funding the stamp and can extend by topping it up.

Which Swarm this page is about

Several projects are called Swarm. This page is about Swarm, the decentralised storage network, run by independent nodes and documented at docs.ethswarm.org. It is not Docker’s Swarm mode, which manages a cluster of Docker Engines, and not DataCore Swarm, an object storage product. “Agent swarms”, groups of AI agents working together, are a different idea again. Answers about one do not carry over to the others.

Content addressing: a changed record gets a new address

Swarm splits an upload into chunks of at most 4 KB. For ordinary data chunks, the address is a hash of the chunk’s content. Swarm’s documentation puts the consequence plainly: “a content-addressed chunk cannot be changed in place. Different content yields a different address.” (DISC)

So nobody, the uploader included, can put different bytes at an address that already holds a record; they can only store a new version at a new address. And whoever holds the address can download the record and recompute the hash; altered bytes would not match.

Each chunk is stored by the nodes whose addresses are closest to the chunk’s address, and the nodes in that neighbourhood keep copies of the same chunks, so a record does not depend on a single machine (DISC).

Postage stamps: how long a record is kept

Every upload needs a postage stamp batch: a prepaid right to store data on Swarm (postage stamps). A batch has two settings, recorded on Gnosis Chain when it is bought:

  • Depth sets how much data the batch can stamp (in practice somewhat less than its theoretical maximum).
  • Amount sets how much is paid per chunk, and so how long the data is kept. The batch balance is slowly used up as blocks are produced, “as if storage rent was regularly deducted”.

The remaining lifetime of a batch is its time to live (TTL). It is an estimate: the storage price is set by a price oracle contract from network use, so the TTL moves when the price moves. The documentation says to check it regularly (stamp batches).

When a stamp expires, its chunks can no longer earn storage rewards, so nodes “will no longer receive rewards for storing them and can safely remove them from their reserves” (postage stamps). Expiry ends the obligation to keep the record. It does not promise that every copy is erased.

Top-ups extend retention. Adding balance to an existing batch increases its TTL. The documentation’s warning is short: “Don’t let your batch run out! If it does, you will need to restamp and resync your content.” (stamp batches).

Immutable or mutable batch. Batches are immutable by default: once full, they accept no more uploads, and nothing already stamped is displaced. A mutable batch keeps accepting uploads when full, and new chunks take the place of the oldest ones in the batch, so an older record can drop out before the batch runs out. Its address still never points to different content. For records you may need as evidence, use an immutable batch; Swarm’s own guidance names “records archival” and “legal documents” as its use (postage stamps).

Feeds are mutable, and a different thing

Swarm also has feeds: a fixed address you can point at new content, used for websites and other things that update (feeds). A feed is built from single-owner chunks, whose address comes from an owner’s key and an identifier rather than from the content. Each update is a new chunk at a new address; per the documentation, “no individual chunk is ever overwritten, meaning the chunk store itself remains immutable” (DISC).

The practical point: a feed address can show different content tomorrow. A content address cannot. For a record that must not change, keep and share its content address, not a feed that points to it.

Deletable content: revoking access (DREAM)

Swarm’s researchers have published a way to delete content from Swarm: DREAM, described in “A dream come true: deletable content in immutable storage” (Viktor Trón and Henning Diedrich, September 2025, paper). It treats deletion as the loss of access, the way most systems do in practice: the uploader shares content through a special reference, and can later revoke it, after which the reference stops working and the content cannot be retrieved without having kept a full copy.

Three points matter for records:

  • It is chosen at upload. Content must be uploaded as deletable from the start; the paper calls this specialisation. Ordinary content-addressed uploads are not affected.
  • Only the uploader can delete. Deletable content is access-controlled, and the uploader’s credentials are needed to revoke access; no one else can.
  • Expiry is not deletion. The paper itself notes that data whose stamp has run out “cannot be regarded as reliably deleted”.

The paper describes a construction for the Swarm network and says implementing it would take only modest changes. Check the current Bee release notes for whether it is available on the network you use.

For evidence, this cuts both ways. Uploading a record as deletable gives you a way to honour a deletion request, but it also means whoever uploaded it can make it unretrievable. A record meant for auditors should be a plain content-addressed upload, so that nobody, the uploader included, can withdraw it before its stamp expires.

What “write-once” means here, and what it does not

It means:

  • The bytes at a content address cannot be replaced; a change shows up as a different address.
  • Until its stamp expires, several nodes are paid to keep the record.
  • The people entitled to check (auditors, evaluators, the client) can fetch it by its address and verify it without trusting whoever stored it.

It does not mean:

  • Kept forever. Retention lasts as long as the stamp is funded. After expiry, nodes may remove the record.
  • Guaranteed available. Nothing beyond a funded stamp keeps the record on the network. A node can pin content so its own copy survives clean-up, but that protects only that node’s copy (pinning).
  • Deletable, for ordinary uploads. For plain content-addressed uploads there is no way for the uploader to withdraw a chunk from the network before its stamp expires; unpinning only affects one node’s pin, and expiry is not erasure. Content that may have to be deleted belongs in a deletable upload (above) or should be encrypted.
  • Private. Whoever has a reference can download the content (upload and download) unless you encrypt it first.
  • True. A stored record shows it was not changed after it was stored. Whoever uploaded it could have written anything into it beforehand.

Using Swarm for records

Free-tier records are kept for about a day; for evidence, use a stamp funded for the retention period you need, on an immutable batch, and watch its TTL.

The Datafund Provenance Toolkit stores agent records on Swarm and returns each record’s address and SHA-256 fingerprint, with an optional notary signature and timestamp. It is pre-release, meant for testing, and runs on a test network (Base Sepolia). The free tier is limited and may fail under heavy load; retry later. The quickest test is dataprovenance.app. The developer post walks through it; the story post explains why it matters.

Related: write-once storage for agent records, how an auditor verifies transcripts, provenance tools compared, what agent provenance is.

Questions people ask

Is Swarm write-once storage? Yes, for content-addressed data: a record’s address is computed from its content, so it cannot be changed in place, and an edited version gets a new address. It is write once, read many with an expiry, because records are kept only while their postage stamp is funded.

How long does Swarm keep data? As long as the postage stamp batch that paid for it has balance. The remaining time (TTL) depends on what was paid and on the storage price, which can change; topping up extends it.

What happens when a Swarm postage stamp expires? Nodes stop being rewarded for storing the chunks and may remove them. Expiry ends the obligation to keep the data; it does not guarantee that every copy is erased.

Can you delete data from Swarm? Yes, if it was uploaded as deletable. Swarm’s DREAM design lets the uploader revoke access to content uploaded that way, so its reference stops working; only the uploader can do it. Ordinary content-addressed uploads cannot be withdrawn before their stamp expires, and expiry is not reliable deletion.

Are Swarm feeds immutable? No. A feed is a fixed address that can point to new content over time. No chunk is overwritten, but what the feed shows changes. For records, share the content address.

Is this the same Swarm as Docker Swarm? No. Docker’s Swarm mode manages a cluster of Docker Engines. This page is about Swarm, the decentralised storage network (ethswarm.org).

Sources