What survives Permafrost, and what does not

This page answers the question worth asking before you store anything anywhere: you hold a receipt id, this instance is not answering, and there is nobody to ask. What do you still have?

What you get from the chain alone

Point any Sui fullnode at the receipt id. It answers with the receipt object: the content fingerprint, the address that minted it (this instance’s operator, not the tenant), the file count and byte total, whether the object was stored encrypted, previous_id — the receipt this one descends from, so the version history walks backwards from here — and the locator of the manifest index.

Fetch that manifest from any public Walrus aggregator and you have the namespace map itself: every key, the blob id it was stored under, and the content fingerprint of each one.

The load-bearing property is where that map is not. It is not a row in a Permafrost database that somebody has to keep serving. The key-to-blob mapping is on-chain structure plus a blob anyone can fetch, which is the difference between a storage provider you can leave and one you cannot.

The boundary, stated exactly

• The receipt is on Sui, and it resolves whether or not this instance, or any operator, is still running.
• Verification needs nothing else. A holder of the original bytes recomputes the fingerprint and checks it against the receipt — without the manifest index, without an aggregator, and without us.
• The map is a blob, readable from any public aggregator while that blob’s lease holds. If it is lost, the owner rebuilds it and re-points the receipt at the rebuilt copy; the receipt has an owner-gated update for exactly that.
• The bytes are on Walrus while their lease holds. → Leases, renewal, and nothing expiring silently
• A byte you can fetch is not a byte you can read. An object’s ciphertext is readable only with its key, so what survives depends on which surface stored it.

Surface by surface

Surface	On Sui	The stored bytes	Who can read them
Ordinary S3 object, server-side encryption	manifest receipt: fingerprint, and lineage where the receipt records it	ciphertext on Walrus while the lease holds	this instance, which holds the key
Custody object	manifest receipt, plus a certificate once incinerated	ciphertext, untouched by incineration, until its lease lapses	this instance while the key lives; nobody afterwards
Bytes your team encrypted before upload	manifest receipt over what was stored	your ciphertext on Walrus while the lease holds	your team, from any Walrus aggregator

The middle row is a design choice rather than a shortcoming: a custody object’s key is destroyable on purpose. → Deletion by key destruction

The bottom row is the answer for a team whose threat model includes us. You give up every server-side feature that needs plaintext, and you keep the receipt. → Encryption at rest

The promise, narrowly

Your record of what was stored, and the proof that the bytes you hold are the bytes recorded, does not depend on us. Retrieving the bytes depends on the storage substrate still holding them — a property of the substrate and its lease, not of the receipt — and anything you do retrieve verifies against the fingerprint on chain.

Those are two different claims, and this site keeps them apart. → A storage receipt is not a provenance receipt