Deletion by key destruction

On an append-only substrate there is no un-write. Once an object’s bytes are encoded and spread across storage nodes, no operation reaches back and removes them — and anything claiming otherwise is describing a database it controls, not a substrate it shares.

What you can do is destroy the only key that reads them, and put the destruction on the record.

One object, one key

The custody surface holds material your application keeps on a user’s behalf: store it, ask its status, serve it while its key lives, delete it by destroying that key. Each object is encrypted under a key of its own, held server-side, rather than under a key derived once per tenant.

That is the property that makes a single object individually forgettable. A tenant-wide key cannot be destroyed for one object without destroying it for every object beside it.

What incineration does, in order

1. The key is destroyed first. Before anything is published, the material that reads that object is gone.
2. Then a certificate is minted on Sui, naming the plaintext’s fingerprint, the storage locator, the key’s identifier, the operator that attests the destruction, and the deletion mode.
3. Reads of the plaintext answer 410 from then on. There is no path back.

The order is the interesting part. Destroying the key first means a failure to mint leaves an unreadable object with no certificate — a gap in the record — rather than a certificate asserting a destruction that did not happen.

The ciphertext stays

Nothing deletes the stored blob. It sits where it was written, follows the same storage policy as any other object, and lapses when its lease lapses. The locator named in the certificate stays valid as a locator: it points at a blob that is still there and can no longer be read into anything meaningful.

The certificate does not claim the blob was removed from Walrus. Reading it as if it did is the misreading this section exists to prevent.

Two hashes, two verifiers

A custody object has two fingerprints, and they are not interchangeable.

Hash	Of what	What it verifies
plaintext hash	the bytes before encryption	the certificate on Sui — this is the hash it names
stored hash	the ciphertext object, as the storage layer recorded it on write	storage provenance, through the keyless verify route

Only ciphertext ever reached the storage layer, so asking the verify route about a plaintext hash correctly answers that no provenance is held for it. That is the route working, not a missing record.

Why the certificate names no tenant

It carries the plaintext fingerprint, the locator, the key identifier, the deletion mode, and the address that attests the destruction. It carries no tenant, no account, and no name.

It does not need one. Whoever holds the original bytes hashes them and matches the fingerprint, and the match is the proof that this certificate is about their object. A tenant field would publish who stored what to every reader of the chain and add nothing to the proof.

What this is called here

Auditable vendor-side deletion by key destruction. The certificate carries that boundary in its own deletion_mode field, so a reader gets it from the object rather than from this page: the key material this instance held was destroyed, an operator attests it, and the claim stops there.

It is not a trustless property — the operator sits in the trust path, and no page can argue its way out of that.

It is a capability, not a legal characterisation of any kind.

Where to go next

• Hold, serve, incinerate — the whole lifecycle, run front to back against the hosted instance.
• What survives Permafrost, and what does not — where a custody object sits among the other surfaces.