Proof the data is gone.
Not a checkbox.

BurnLedger issues Verification Records: independent, cryptographic proof a person's data was present in your systems, then absent. Signed inside sealed hardware. Logged in public. Signature verifiable by anyone, forever — no account, no API, no us.

A person rendered as flat color planes, each plane a datastore — Postgres, S3, Redis, Mongo, BigQuery — with one shoulder breaking apart into scattered squares.
Get started Verify a record

Self-serve · start in minutes · read-only access, always

  1. Attest

    One call snapshots the subject. We query your systems, hash the matching records in memory, and discard the raw data. Only hashes are kept.

  2. Delete

    You delete the data with your own tools, your own process. We are not in the loop. You keep full control of the erasure.

  3. Verify

    A second call re-queries your systems. Data gone? The attested enclave signs a verification record. Still present? Nothing is issued.

  4. Certify

    An Ed25519 verification record is issued and appended to a public transparency log. Anyone can check the signature and the inclusion proof offline. That much is math, not trust.

Regulators can require deletion — GDPR Article 17, CCPA, California's Delete Act. What they ask for next is the hard part:

“Prove it's gone.”

A Jira ticket is a promise. An internal log is self-attestation. A screenshot is a screenshot. None of them let an auditor independently confirm the records are actually absent.

Privacy platforms like Transcend and OneTrust orchestrate the deletion workflow and mark it done on a dashboard. They don't cryptographically verify the data is gone. That's the gap BurnLedger fills.

The artifact is a record
you don't have to trust us for.

Two API calls to create one. Zero to verify it. An Ed25519 signature is standard cryptography; any library checks it. If BurnLedger vanished tomorrow, every record we ever issued stays valid.

Verify a record

Why the signature means something

The key never leaves the hardware.

No one at BurnLedger can sign a verification record by hand. The Ed25519 signing key exists only inside an AWS Nitro Enclave: sealed hardware that measures the code it runs. AWS KMS releases the key to that exact measured build and to nothing else. The build is deterministic: we rebuild every release from the same commit and confirm it measures identically. We do not publish the source or toolchain that would let you repeat that rebuild, and that is a settled decision rather than a gap we are working on — the enclave source is the product. So that particular check is ours, not yours, and we would rather say so than imply a publication that is not coming. What a certificate carries for you to check is the signature and the log entry: it holds no hardware attestation, so enclave custody is our operational claim, not your arithmetic. What we can do is put the claim somewhere we cannot quietly edit: every measurement we have run in production is published with its date at enclave measurements.

Signing keys are published →

Every record, nailed to a public log.

We can't deny a record, and we can't backdate one. Each one is written to an append-only Merkle transparency log (RFC 6962) with an inclusion proof. It's the same construction that keeps the web's certificate authorities honest. Anyone can check a certificate against that log, your auditor included. No BurnLedger account needed.

Read the signed tree head →

Don't take this section's word for it either. Watch a real record verify in your browser →

Attest. Delete. Verify.

Two calls around your own deletion. Read-only credentials only — checked against the engine's own privilege tables wherever the engine can answer, and where it can't, we refuse to connect without your explicit read-only assertion.

npm i burnledger pip install burnledger

Read the docs →

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");

Twenty connectors. Twenty-two systems they cover.

  • PostgreSQL
  • Neon
  • Supabase
  • MySQL
  • SQL Server
  • Oracle
  • MongoDB
  • Redis
  • Elasticsearch
  • Cassandra
  • DynamoDB
  • Neo4j
  • Amazon S3
  • Azure Blob
  • Google Cloud Storage
  • Redshift
  • Snowflake
  • BigQuery
  • Databricks
  • Teradata
  • HBase
  • MarkLogic

Read-only is enforced against the engine’s own privilege catalog wherever one exists. Where none does — Azure Blob, HBase, MarkLogic — we record your assertion, and the record says which of the two it was rather than claiming both are the same thing. Need one we don’t list? We’ll build it.

We prove your deletion
without ever holding your data.

Records are hashed, then dropped. In the default count mode only a number crosses the wire. In Merkle mode the matching rows do pass through connector memory — where they are hashed and discarded on the spot. Either way no record content reaches our database: the schema has nowhere to put it. The one place your engine's own output can land on our side is an operational log line when a connection fails, and credentials are scrubbed from it.

We never store raw identifiers. Subject identifiers are salted with SHA-256 using your customer salt and only the hash is retained; the plaintext lives in memory only during a query. We treat that hash as personal data, because with our salt it still points at a person.

Records outlive us — with one exception we would rather name. Ed25519 is standard cryptography and the transparency proof is arithmetic: both verify offline, with any library and no account, for as long as the file exists. Revocation is the part that does not. A verifier given no fresh status statement reports unknown, never valid, because “not revoked” is not a property anyone can establish offline. Keep a copy of our published signing keys alongside the certificate and everything else survives us.

Check it, don't trust it. The two signatures and the transparency proof are yours to verify offline, with any crypto library and no account. Where a claim rests on how we run our infrastructure rather than on arithmetic you can do — that the signing key never leaves the enclave — we say so plainly instead of dressing it as proof. Everything here is public and checkable today: the signed key list, the live transparency log, the full measurement history, the CC0 deletion addendum, and the SDKs on npm and PyPI.

Common questions

What is a deletion certificate?

“Deletion certificate” is the term most people search for. BurnLedger calls what it issues a Verification Record, because nothing here is attested by an authority — the signature and the public log are what you check. It is a single portable JSON document proving that a data subject’s records were present in named systems at one moment and absent at a later one — the evidence a right to be forgotten request leaves behind. It carries both observations, two Ed25519 signatures, and a transparency-log inclusion proof, so anyone holding the file can check it offline without a BurnLedger account and without asking us anything.

Does it prove all of a person’s data is gone?

No, and the record says so on its face. It proves the outcome of specific queries against specific registered systems. It says nothing about systems that were never registered, data the queries do not match, or copies held outside the queried stores. The scope is exactly the systems and query hashes named in the file — which is why those are named in it.

How is a verification record revoked?

Revocation is not a field inside the record, because a signature commits to bytes at one instant and revocation is discovered afterwards. A separate signed status statement carries it, with its own validity window: a fresh ACTIVE statement means the record stands, REVOKED means it was withdrawn, and silence means unknown — never valid.

Can it be verified without an account?

Yes. Drop the JSON into the verify page and every check runs in your own browser tab, or install either SDK and run the check entirely offline against a saved copy of the published signing keys. Ed25519 signatures and RFC 6962 inclusion proofs are standard cryptography: an engineer with a common crypto library can re-implement the checks from the record alone.

Where this fits in your compliance work

Article 17 of the GDPR gives a data subject the right to erasure — the right to be forgotten — and obliges a controller to act on it. What the regulation does not do is tell you how to show, afterwards, that you did. That gap is usually filled by a signed letter from the party with the strongest reason to say the work was done. A verification record replaces that letter with audit evidence a third party can check for themselves: two signatures over canonical bytes, an inclusion proof in a public log, and a named scope. It is not a compliance programme and it does not make you compliant; the DPO or counsel on your side decides what your obligations are, and this is one piece of evidence they can put in front of a regulator or a customer’s auditor. What BurnLedger itself does with data, and what it deliberately does not hold, is set out in security and in what a record proves.

Put it in the contract.

The Verifiable Deletion Addendum is DPA language that requires evidence of deletion a controller can check offline — no supplier named, no account needed. Public domain under CC0: copy it, edit it, hand it to counsel.

Copy the clause Read the annotated addendum →

Pricing

SB 362 penalties run $200 per request, per day — and from 2028 brokers must undergo an independent third-party audit of their deletions. BurnLedger is the evidence to bring to that audit.

On every plan, down to a single verification record: it lands in the same public transparency log, verifies offline against the same published keys, and comes with webhooks, CSV / JSONL export, and the API and SDKs. The only thing that changes with price is volume. Most teams start on Just a few and move to a monthly plan once they pass roughly 350 records a month.

Just a few

$1/ verification record

  • Pay only for what you issue
  • 2 systems
  • No monthly fee, no minimum
  • Real verification records, same signing key
Get started

Proof

$349/ mo

  • Up to 1,000 verification records / mo
  • 5 systems
Get started
Recommended

Scale

$1,250/ mo

  • Up to 15,000 verification records / mo
  • Unlimited systems
  • Now live: batch-run attestation covering an entire DROP cycle, and the Audit Pack evidence bundle.
Get started

Enterprise

Custom

  • Everything in Scale
  • Unlimited verification records
  • Named contact, by email
Talk to us

Prices are monthly, cancel any time — access runs to the end of the period you paid for.

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

Prove your next deletion.

Sign in with Google, pick your plan, and pay by card. No sales call, no waitlist — you’re issuing real verification records into the public log in minutes.

Start with Google

Checkout by Stripe. Read-only access, always.