Deletion guarantee

When a baton is deleted — whether you force it, schedule it, or it burns after its last read — the content is destroyed. This page says exactly what “destroyed” covers, what survives, and why the few things that survive are not your content.

What gets destroyed

A baton’s content lives in exactly one of two places per entry, and deletion destroys both:

Large content is stored as an object in Relaystation’s content bucket. Deletion issues a hard delete of every one of those objects.
Small content is stored inline in the database row for the entry. Deletion removes the row, and the bytes with it.

There is no third copy. A baton entry holds its content in one of those two homes (never both), and the purge destroys whichever it is — every entry, the blob and the row together.

The timeline

Deletion happens in two observable steps:

Delete (immediate). The moment a baton is deleted — by your DELETE call, by a scheduled disposal, or by burn-after-reading consuming the last read — it becomes unreadable. Reads return 410 Gone. From your side, it is gone now.
Purge (shortly after). A background process destroys the underlying blobs and payload rows. This is what reclaims the storage. It runs on a short cycle, so physical destruction follows the logical delete by a small window, not instantly in the same request.

If you chose a hard delete, step 1 goes straight to the deleted state. If you chose the default soft delete with a grace period (tombstone), there is a recoverable window first — you can undo the delete during the grace period; once it expires, the baton moves to deleted and is purged. The grace window is your safety net, not a leak: a tombstoned baton is already unreadable to everyone else.

What survives — and why it is not your content

Two things deliberately outlive the content. Neither is the content itself:

Your receipts (the ledger). Every charge and credit keeps its ledger row — the money history. These rows record that you were charged, the amount, and the reason. They carry no baton content — they are accounting, and you keep them so your spending stays auditable. Deleting a baton never erases the financial record of having used it.
The trust attestation (if you witnessed the baton). When you enable the document-witness, Relaystation signs a SHA-256 hash of the content and keeps that signed record for about seven years so anyone can still verify a copy you hold against it (see Trust). What survives is the hash and the signature — never the content. A hash is a one-way fingerprint: it lets someone confirm a document they already have matches what was witnessed, and it reveals nothing about the document to someone who doesn’t. After the retention window, even the hash and signature are scrubbed; only the bare fact that a witness existed remains as an audit marker.

So: the content is destroyed; what remains is a record that you spent money, and — only if you asked for it — a fingerprint that proves authenticity without disclosing anything. That is the whole of what survives.

In one line

Delete a baton and the content is gone — blobs hard-deleted, payload rows removed. The only survivors are your ledger receipts (money, no content) and, if you witnessed it, a signed content hash (a fingerprint, not the content), kept so verification keeps working and then scrubbed.