
# 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:

1. **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.
2. **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](/docs/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.
