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.


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 takeDecentralized hosting — no server to run, no middleman to depend on.
Read it as vision
A website can vanish through a suspended account, a blocked domain, or a provider outage; Swarm removes those single points of failure by not needing anyone's server in the first place.
Read it as development
Beeport, Swarm Desktop, or swarm-cli each upload a build, buy a stamp, and point an ENS name at the result.
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

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.
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.
Where to go next
The architecture is one part of the picture
Understand how it works, contribute to it, see what's being built on it — or start building today.
Developer HubBuild on it
The tools are ready: Bee‑js, swarm‑cli, Feeds, ACT and PSS. Where you go from understanding the architecture to building on it.
Run a NodeBecome a peer
Running a node is the most direct way to take part - store chunks, relay data, and earn xBZZ through the redistribution game.
CollaborationsFind it in the wild
Real teams are building on the architecture you just read about. See what is in production, what is in progress, and who is behind it.
TokenomicsGame theory, not goodwill
How postage stamps are priced, how the redistribution game works, and what drives node rewards - the incentive layer in full.