Inside Swarm

Run by everyone, hosted by no one

Every file is found by what it contains, not by where it sits, so no single machine has to be online for it to exist.

Swarm network at a glance


  • User-run network

    Independent participants, no single company

    Availability and access don't depend on any one vendor. If some nodes go offline, the network continues — there's no central switch to turn off.

  • Permissionless

    No gatekeeper decides who can participate

    Publish, retrieve, or run infrastructure without asking for approval. Participation is open by design. It’s written into the protocol.

  • Bee client

    The software connecting you to Swarm

    Bee is the node software. Run it to become a peer in the network rather than a user of someone else's infrastructure.

  • Content addressing

    Links that point to data, not servers

    A content hash address means: "fetch this exact data from whichever computers have it." Links can't break because a server went down. Content can't be silently replaced.

  • Incentive mechanism

    Bandwidth is paid for. Storage is rewarded.

    Publishers buy postage stamps to upload data. Payments flowing through the network's incentive mechanism are distributed to nodes that store data reliably.

  • Erasure coding

    Data survives even when nodes don’t

    Chunks are stored with enough redundancy that the original can be reconstructed from partial copies. Data stays safe even if several nodes go offline at once.

The Bee client

Everything runs in Bee

Every primitive that makes Swarm distinct is implemented in a single piece of open-source software. When you run Bee, you become a peer in the same network everyone else is building on.

Bee at the centre of the network, with the primitives it implements around it: SWAP, content addressing, feeds, erasure coding, access control (ACT), postage stamps, PSS and GSOC.
Bee at the centre of the network, with the primitives it implements around it: SWAP, content addressing, feeds, erasure coding, access control (ACT), postage stamps, PSS and GSOC.

How data moves in the network

From upload to retrieval — no server required

When you upload data to Swarm, a precise sequence of events ensures every chunk finds a home and can be retrieved by anyone with the address. Here's what happens.

Your file is split and prepared for the network

When data is uploaded, Bee splits it into 4KB chunks. Each chunk is assigned a content-derived address — a hash of its own content — so its identity is inseparable from what it contains. One extra chunk, the root chunk, holds nothing but the addresses of the others, so a single address stands for the whole file. The full set of chunks is then ready to be pushed.

Incentive design

The network is designed to fund itself

Storage isn’t free — and we won’t pretend otherwise. Reading from Swarm costs nothing. Storing data is paid for like rent: you choose how long it's kept, and top up to keep it longer. That money pays the nodes that store your data, and they only earn it by doing the work.

Pricing, rewards and the token are covered in more detail on the Tokenomics page

DOWNLOADS

Free

Anyone can retrieve public content without a wallet or tokens.

STORAGE

Rented

You pay for how long data is kept. Prices adjust automatically: more demand, higher price; more nodes, lower price.

WHO EARNS

Node operators

Nodes that store data and pass it along are paid from what uploaders spend.

KEEPING IT HONEST

Verified

Nodes regularly have to prove they still hold the data they're paid to keep. Nodes that don't are frozen out.

Privacy by design

Control, consent, and protection from silent exploitation

Privacy on Swarm isn't a single switch — it's a set of tools you choose to use. The network is public by default; the primitives below give you control over who can access what, and on whose terms.

  • E2EE — CONFIDENTIALITY

    Encrypted storage on a public network

    Swarm can store encrypted data so only people with the key can read it — even though the network itself is public. This shifts privacy from trusting a host to controlling keys. Storage and delivery can be decentralised without exposing the contents.

  • ACT — CONSENT AND ACCESS

    Cryptographic permissions, not platform accounts

    Access Control Trie lets builders define who is allowed to access what, using cryptographic permissions rather than platform accounts. It enables subscriptions, gated access, and private sharing — without a central authority deciding who gets in.

  • FEEDS — UPDATABLE CONTENT

    Dynamic content without breaking links

    Feeds are signed, versioned pointers — a stable reference that can publish new versions over time without breaking links. Updates are authenticated, not silently replaced by a host. You can build profiles, indexes, and websites that evolve while remaining verifiably yours.

A note on full privacy: Light and ultra-light nodes are always the originator of their requests — they don't benefit from plausible deniability. PSS private messaging is only available to full nodes.

Possibility spaces — Architecture

How Swarm’s architecture supports a better web

Each story here reads three ways: imagine it, understand it, build it. This page leads with understanding it: the parts of Swarm that make it possible.

Decentralized Frontend

ClaimedYours to take

Decentralized hosting — no server to run, no middleman to depend on.

Architecture

A site on Swarm doesn't live on a server. Uploading it splits the files into fixed-size chunks, each addressed by the hash of its own contents, and scatters them across Swarm's shared storage layer, the same layer every other piece of content on the network uses. No single node holds the whole site, and no single node needs to be reachable for someone else to load it; a chunk is served by whichever nodes happen to be holding it.

A root manifest ties the chunks back together: it's the map from a file path like /index.html or /assets/logo.svg to the chunks that hold it, so a single reference is enough to reconstruct the entire site. Uploaded once, that manifest reference would normally be fixed forever — a new version would mean a new, different reference.

A feed makes it possible to update. A feed is a Single Owner Chunk that only the site's owner can write to, holding a pointer to the current manifest. Publishing a new build means writing a new manifest reference to the feed; the feed's own address doesn't change, so a link shared once keeps resolving to whatever the latest version is.

Keeping all of this available costs postage stamps, paid upfront by whoever uploads the site, funding the nodes that store the chunks for the stamp's duration. This replaces a hosting bill: instead of paying a company every month to keep a server running, a stamp pays the network directly, for a duration chosen at upload time and extendable later. For a human-readable address, the feed can be linked to an ENS name, so a hash-based reference resolves from something like yourname.eth instead.


  • Content addressing
  • DISC storage
  • Manifests
  • Feeds / Single Owner Chunks
  • Postage stamps
Architecture diagram: Decentralized Frontend
FIG. 01 ref d98b…684f
Architecture diagram: Decentralized Frontend

How Swarm differs

Honest comparison with alternative approaches

The devil is in the details. The differences that matter are in the incentive design, privacy primitives, and what the network can actually do today.

SwarmIPFSFilecoinArweave
Storage incentivesBuilt-in redistribution game, automaticNone by defaultDeal-based, requires negotiationEndowment model, one-time payment
Bandwidth incentivesSWAP — automatic, peer-to-peerNoneNone for retrievalNone
Privacy primitivesE2EE, ACT, plausible deniability (full node)None built-inNone built-inNone built-in
Private messagingPSS (full nodes)libp2p pubsub onlyNoneNone
Mutable contentFeeds (signed, updateable)IPNS (slower, less reliable)LimitedNone
Upload cost modelPostage stamps (prepay for time)Free (no persistence guarantee)Storage deals (market-based)One-time permanent payment
Node incentive to storeIncentive to storeYes — redistribution rewardsNoYes — deal paymentsYes — endowment interest
Developer maturityGrowing ecosystem, active developmentLarge ecosystem, widely adoptedMaturingNiche but growing

IPFS has the largest developer ecosystem today. Swarm's advantage is in its integrated incentive system, privacy primitives, and bandwidth compensation — features IPFS lacks by design.