Revocation certificates

A user withdraws their data and gets a certificate, signed by the deployment, of what was deleted and when, checkable without trusting the app.

Example: a contributor leaves a dataset. They sign one request for their prefix; every file under it is deleted, and they get a certificate. Every warranty that named those files records the withdrawal.

Asking for one

The owner signs a request naming a bucket and a key prefix (or the whole bucket).

• The signature is the only credential. Your app doesn’t have to cooperate.
• Everything under the prefix is deleted, checked gone, then certified.
• Resending the same request returns the same run. If a delete fails, the run is marked partial and resending finishes it.

What the certificate says

• What was revoked: deployment, tenant, bucket and prefix.
• Which objects: how many, and exactly which keys.
• When the deletes ran.
• Where they went: deleted from the deployment, and whether every Walrus copy was scheduled for removal, not all were, or there were none.
• Its place on the public ledger, signed by the deployment.

It is our statement of the deletes we ran our statement, and doesn’t claim bytes on Walrus are unreadable. For that, use custody.

Check it without us

• The signature checks against the deployment’s ledger key. verifiable
• The summary is a public ledger entry, checkable against Sui once published. It commits to exactly which objects went without naming them. verifiable

The certificate itself lists keys, so it isn’t public. The owner reads it with their credential or the original request.