Tombstone — Cryptographic Notary

Tombstone is a cryptographic notary for data lifecycle events. It records what happened, signs the chain, and issues a certificate no party can alter without detection.

A deletion occurred. Tombstone received the completion event, signed it, and stored the chain. The evidence is created at event time, not reconstructed later.

Deletion without documentation is a statement. Tombstone makes it a record.

CPPA §7122 holds that audit findings cannot rely primarily on management assertions. Tombstone provides the independent third-party record that satisfies that standard.

Request a Demonstration

tombstone — verify

One job, from first event to certificate

Lifecycle events

tombstone — lifecycle events

Certificate

CRYPTOGRAPHIC DELETION CERTIFICATE

Certificate No.

TS-2026-6e1dabe81c9a

Issued July 18, 2026 16:18 UTC

Regulation

CCPA 1798.105 — Right to Delete

Deletion Status

VERIFIED

Versions Deleted

1 of 1

Events in Chain

6 — signed, hash-chained

Algorithm

Ed25519

Retained Until

July 18, 2028

Scope Hash — one-way only. No raw identifiers held by Tombstone.

sha256:b24a730c7d39cf4d883a79e1d4ae2c32f1db683bdb8b12c45f3c61ca076a31cd

One Protocol, Any Driver

driver · byob

S3 deletion evidence — in your infrastructure

The agent runs on your side. It enumerates, purges, and verifies against your S3, then mints a 6-event chain — window opened through zero-versions-verified — without a raw bucket name or object key ever reaching Tombstone.

GDPR Art. 17 · CCPA 1798.105 · scope_hash one-way commitment

driver · drop

DELETE Act batches — one certificate per transaction

For California's DROP program: a batch audit chain records the download-process-upload cycle, and each deletion transaction gets its own child chain and its own tombstone_id — nested under the batch that produced it.

CA DELETE Act §125300 · 45-day cadence · batch ⊃ per-DSR

nesting

Lineage is verified, not asserted

A child chain commits to its parent's tombstone_id inside its signed genesis event. Verification checks that the parent exists on the ledger, belongs to the same tenant, and sealed before the child began. A chain cannot claim an ancestry the ledger does not hold.

PARENT_TOMBSTONE_NOT_FOUND · PARENT_TENANT_MISMATCH · CHILD_PREDATES_PARENT

versioning

Chains verify forever

Every event names its schema version inside the signed record, and verification applies the frozen ruleset for that version — schema, privacy denylist, and chain grammar. Protocol upgrades never orphan an issued certificate.

ruleset pinning · schema 3.2.0 current · earlier versions frozen

What a certificate proves

The protocol ran in this exact sequence, and the chain has not been altered since signing.
These claims were made under this tenant's credentials and signed at this timestamp.
The record predates the query — evidence created at event time, not reconstructed for an audit.

What it does not prove

That the agent's reports about the target system were accurate. Tombstone witnesses the protocol, not your storage.
What the target was. Structurally: the scope_hash is one-way, and Tombstone never holds the pre-image.

The boundary

What crosses the wire — and what cannot.

Your driver resolves the target, performs the deletion, and computes scope_hash locally: HMAC(scope_secret, tenant:target). The secret stays in your infrastructure. Tombstone never receives it.

What it does receive is on the right — a real minted event. Read it for what is absent: no bucket, no object key, no URL, no email, no customer record. Tombstone cannot reveal a target under subpoena because it was never sent one.

Current event grammar: schema 3.2.0. Every event is validated against the frozen ruleset named by its own signed schema_version — chains minted on earlier versions verify forever.

POST /api/tsledger/lifecycle/mint-next Authorization: Bearer <token>

// a real minted event — the terminal event of the specimen chain above.
// mint-next injects event_time, nonce and prev_event_hash server-side.
{
  "schema_version": "3.2.0",
  "event_type": "byob.deletion_complete",
  "privacy_mode": "PRIVACY_FIRST",
  "job_id": "5fd3e03e-147b-5ffc-8d9f-2a2c8d93fd42",
  "run_id": "de1cd676-28f2-491f-9f96-488406a37abc",
  "tenant_ref": "demo-tenant",
  "scope_hash": "b24a730c7d39cf4d883a79e1d4ae2c32f1db683bdb8b12c45f3c61ca076a31cd",
  "claim": {
    "purpose": "RETENTION_EXPIRY",
    "requested_by": "AUTOMATION_POLICY",
    "policy_ref": "realledger-e2e"
  },
  "track": {
    "driver": "aws_s3_byob_purge",
    "driver_version": "0.1.0",
    "environment": "DEV",
    "attempt": 1
  },
  "scope_key_id": "aae686b50ff546af",
  "details": {
    "completed_at": "2026-07-18T16:18:10Z",
    "result": "SUCCESS",
    "summary": {
      "listed_versions": 1,
      "listed_delete_markers": 0,
      "successful_deletes": 1,
      "failed_deletes": 0
    }
  }
}

// the real response — terminal event returns tombstone_id
{
  "event_hash": "6e1dabe81c9ac8917ad2c384b44f67bad740a98679934059fece317587b3f3bf",
  "kid": "1a1f59bd616dc808",
  "tombstone_id": "TS-2026-6e1dabe81c9a"
}

Enforced, not requested

Send a raw identifier and the mint is refused. The denylist runs at the boundary, before signing — nothing is scrubbed, quarantined, or stored and filtered later. Rejected keys include bucket, object_key, url, prefix, secret and token.

{ "details": { "bucket": "acme-prod-users" } }

HTTP 400
{
  "detail": {
    "code": "PRIVACY_GUARDRAIL",
    "message": "Forbidden key detected by privacy denylist.",
    "meta": { "path": "details.bucket" }
  }
}

Run it now

Verification needs no account, no token, and no cooperation from the company that issued the certificate. This is the whole regulator-facing surface:

curl · bash

curl -s https://ledger.tombstone.sh/api/tsledger/lifecycle/verify/ts/TS-2026-6e1dabe81c9a

Invoke-WebRequest · PowerShell

(Invoke-WebRequest https://ledger.tombstone.sh/api/tsledger/lifecycle/verify/ts/TS-2026-6e1dabe81c9a).Content

Returns ok, the violation list, the full receipt, and the signing key id — the same result any auditor gets.