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

  1. Main site — https://walrus.xyz/

    • Positions Walrus as a Verifiable Data Platform for AI and onchain finance.
    • Useful mainly as classification and framing material, especially the claim that availability, integrity, and programmability are built into storage itself.
  2. 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.
  3. Core concepts / architecture — https://docs.wal.app/docs/system-overview/core-concepts

    • Most important operational source.
    • Explains blobs, Sui Blob/Storage objects, 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.