Proof the data is gone.

1. 01 Attest

   18:13:24Z

   2

   One call snapshots the subject: BurnLedger queries your systems, hashes the matching records and discards the raw data. Only hashes are kept.

2. 02 Delete

   in between

   you

   You delete with your own tools and your own process. BurnLedger is not in the loop: its credentials are read-only.

3. 03 Verify

   18:13:33Z

   0

   A second call runs the same query again. Data gone? The record is signed. Still there? Nothing is issued.

4. 04 Certify

   18:13:33Z

   #33

   The record, signed with Ed25519, is appended to a public, append-only transparency log (RFC 6962) with its inclusion proof.

$ curl -s https://api.burnledger.io/.well-known/burnledger-keys | jq .data > keys.json
$ npx burnledger check --cert certificate.json --keys keys.json
Verification record dc_2403ce: VALID_REVOCATION_UNKNOWN (offline — nothing was asked about revocation, so nothing is known; re-run with --online to fetch a signed status statement)
  Subject: sha256:a41195...
  Format version: 3.0
  Systems: 1 (postgresql [existence])
  Records before: 2
  Records after: 0
  Records [demo-users]: 2 at attestation, 0 after deletion
  Committed: 2026-08-19T18:13:24Z
  Verified: 2026-08-19T18:13:33.918793335Z
  Registration: not stated (format 3.0 predates the field; its absence is not a pass)
  Transparency log: entry #33, inclusion proof VALID
  Key statuses: signed key_list.v3, VALID until 2026-10-25T09:37:16Z
  Key list trust: the list is signed by a key inside itself — trust-on-first-use, not proof; pin this file and compare it on later runs
$ echo $?
0

$ sed 's/"attested_count": 2/"attested_count": 3/' certificate.json > tampered.json
$ npx burnledger check --cert tampered.json --keys keys.json
Verification record dc_2403ce: INVALID (certificate signature is invalid)
$ echo $?
1

Run on 24 October 2026 with the burnledger 0.10.0 package from npm, on the sample record above. "Revocation unknown" is not an error: revocation is the one thing that cannot be known offline, and the checker says so instead of calling it valid. The same check runs in the browser at burnledger.io/verify.

GDPR Article 17CCPA / CPRACalifornia Delete Act (SB 362)

Deletion laws differ; the fact they demand doesn't: data present, then absent. One record, any jurisdiction.

import { BurnLedger } from "burnledger";

const bl = new BurnLedger({ apiKey: process.env.BURNLEDGER_API_KEY });

// before you delete — snapshot the subject
const att = await bl.attest("user@example.com", {
  systemIds: ["sys_pg_users", "sys_s3_uploads"],
});

// after you delete — verify. This ISSUES the record.
const res = await bl.verify(att.id, "user@example.com");
await bl.savePdf(res.certificate.id, "certificate.pdf");

The example is the one on BurnLedger's site. Azure Blob, HBase and MarkLogic have no privilege catalog to ask: there BurnLedger records your read-only assertion, and the record says which of the two it was.