Walrus primary sources — 2026-05-09
Classification takeaway
Walrus is best cataloged as Sui-coordinated blob-storage infrastructure rather than generic decentralized storage. The key reusable mechanism is the combination of onchain storage/blob objects, a storage-node committee, availability certificates, and RedStuff erasure coding. The main analytical value is that availability, pricing, storage-capacity rights, and committee governance are all exposed as explicit protocol surfaces rather than hidden behind a storage API.
Primary sources reviewed
-
Main site — https://walrus.xyz/
- Positions Walrus as a
Verifiable Data Platformfor AI and onchain finance. - Useful mainly as classification and framing material, especially the claim that availability, integrity, and programmability are built into storage itself.
- Positions Walrus as a
-
Docs landing page — https://docs.wal.app/
- Gives the clearest short statement that Walrus is decentralized blob storage on Sui with high availability guarantees using erasure coding.
- Helpful for distinguishing the protocol from generic web-hosting or CDN framing.
-
Core concepts / architecture — https://docs.wal.app/docs/system-overview/core-concepts
- Most important operational source.
- Explains blobs, Sui
Blob/Storageobjects, shard-to-node assignments, epoch structure, committee assumptions, and optional aggregator/publisher roles. - Important for identifying the real control surfaces: shard honesty thresholds, storage epochs, object/event semantics, and the point-of-availability path.
-
Operations — https://docs.wal.app/docs/system-overview/operations
- Best source for the actual storage flow.
- Details the register → upload slivers → collect signatures → certify availability path and the availability guarantees attached to the PoA.
-
Storage costs — https://docs.wal.app/docs/system-overview/storage-costs
- Important because pricing is part of the protocol mechanism, not just ops guidance.
- Shows WAL-denominated storage fees, SUI-denominated transaction fees, the storage fund, upload-fee logic, and the approximate 5x encoded expansion assumption exposed to users.
-
RedStuff docs — https://docs.wal.app/docs/system-overview/red-stuff
- The most important mechanism page after core concepts.
- Explains the Twin-Code / RaptorQ lineage, the roughly 4.5x overhead target, and why efficient failed-node recovery is a distinct design goal beyond ordinary erasure coding.
-
System info / staking linkage — https://docs.wal.app/docs/system-overview/view-system-info
- Shows that committee data, prices, and storage metadata live in the Walrus system object and are determined by 2/3 agreement each epoch.
- Explicitly states that committee changes are handled by staking contracts implementing delegated proof of stake around WAL.
-
Official paper — https://docs.wal.app/walrus.pdf
- The formal technical paper (
An Efficient Decentralized Storage Network). - Provides the strongest backing for the RedStuff mechanism and Walrus’s storage/recovery tradeoff claims.
- The formal technical paper (
-
Docs map / llms.txt — https://docs.wal.app/llms.txt
- Useful concise inventory of official docs, especially for quickly locating system-overview, cost, and encoding pages.
-
Official GitHub repo — https://github.com/MystenLabs/walrus
- Confirms a live codebase and makes the Move contracts and client implementation inspectable.
Whitepaper / technical-doc status
- The official Walrus paper has been saved locally as
walrus-whitepaper.pdf. - The docs set is strong enough to understand the storage flow, but the paper is still the best source for the underlying encoding/recovery thesis.
Why it stays in the active corpus
- Gives a strong comparison class for decentralized storage systems that expose storage capacity and availability as onchain programmable resources.
- Sharpens the distinction between distribution, durability, and verifiable availability by tying assurance to committee signatures, epoch governance, and host-chain objects.
- Useful for reasoning about where practical authority sits when a storage protocol depends on staking contracts, committee thresholds, object metadata, and token-priced storage epochs rather than only on content addressing.