When you upload a file to a normal server, the story feels finished. The server confirms the upload, stores the file, and you move on. In decentralized storage, the upload is only the beginning. The real work starts after the network has agreed that the blob should be available.
Walrus is designed around that reality. It is a decentralized storage protocol for large, unstructured data called blobs. A blob is a file or data object that is not stored as rows in a database table. Walrus supports storing blobs, reading them, and proving and verifying their availability. It is designed to stay reliable even if some storage nodes fail or act maliciously. Walrus uses the Sui blockchain for coordination, payments, and availability attestations, while keeping blob contents off-chain. Only metadata is exposed to Sui or its validators.
Walrus defines a Point of Availability, or PoA. PoA is the moment when Walrus takes responsibility for keeping a blob available. Before PoA, the uploader is responsible. After PoA, Walrus is responsible for the blob for the stated availability period. This is important because it tells you when the network’s obligations begin.
But PoA does not mean every node already has every piece it needs. PoA means the system has enough evidence to accept responsibility, and then the network begins its internal cleanup and resilience work.
Walrus stores blobs using erasure coding. Instead of copying the full blob many times, it encodes the blob into many parts and spreads those parts across shards managed by storage nodes. This design allows the blob to be reconstructed even when some nodes are unavailable or faulty. But it also creates a practical requirement: nodes need to be able to recover missing pieces so the system stays healthy across time.
This is why Walrus describes a post-PoA sync behavior. After the availability event is emitted on Sui, storage nodes learn that the blob is now officially available. Nodes that are missing metadata or slivers for that blob will seek to download what they lack. In simple terms, the network fills in gaps after PoA. It spreads the responsibility more evenly, so a later reader is not relying on a narrow subset of nodes.
This post-PoA behavior matters because decentralized networks are never perfectly synchronized. During upload, some nodes may be slow. Some may be offline temporarily. Some may miss messages. If the system required perfect delivery during the upload window, it would fail too often. Walrus tries to tolerate imperfect delivery and then repair it once the blob’s status is settled.
That also connects to Walrus’s Byzantine assumptions. The protocol assumes that within each storage epoch, more than two-thirds of shards are managed by correct nodes, and it tolerates up to one-third being faulty or malicious. The practical meaning is that the network expects some slivers to be missing or wrong, and it expects recovery to be necessary. The goal is not to avoid failure. The goal is to keep the blob retrievable despite failure.
Recovery is also tied to integrity. Walrus uses a blob ID that is derived from the blob’s encoding and metadata. Storage nodes use it to check that the slivers they store match what was intended. Readers use it to verify what they reconstruct. This protects the network from a different kind of failure: not missing data, but wrong data.
If the writer encoded incorrectly, Walrus describes how honest storage nodes can detect inconsistency during recovery attempts. If a correct node cannot recover a valid sliver, it can generate an inconsistency proof. Storage nodes can sign and aggregate that proof into an inconsistency certificate and post it on-chain. When the blob is marked inconsistent, reads resolve to None. This prevents a blob ID from becoming a source of conflicting results.
So post-PoA work includes two things. It includes syncing and recovery for normal cases, and it includes detection and containment for incorrect encoding cases. Both are part of keeping the system coherent.
For builders, this has a useful implication. After PoA, you can treat the blob as the network’s responsibility, but you should also understand that the system is doing background work to improve resilience. This is one reason Walrus can remain compatible with fast delivery layers like caches. Hot content can be served quickly while the network continues to maintain its internal consistency and availability.
For users, the benefit is subtle. You usually do not see the sync work. You see its result later, when a node goes offline and the blob still reads. You see it when a cache misses and reconstruction still works. You see it when the system stays calm through normal turbulence.
In short, Walrus does not treat upload as the end of storage. It treats upload as the start of responsibility. PoA is the moment the network accepts the job. The work that follows is the job being done.
