How verification works.
Someone handed you a BurnLedger verification record: an auditor's brief, a regulator's file, a vendor's proof. This page is for you. You need no BurnLedger account, and nothing on this page asks you to trust BurnLedger: every check runs on your machine against published keys and a public log.
The fastest check: in your browser
Open burnledger.io/verify and drop the verification record JSON in. The checks run locally in the tab; the verification record never leaves your machine. Want to see it work before you have a real file? Run the worked example.
Offline, with the CLI
Both SDKs ship a burnledger CLI. It needs two files and no network:
# The published signing keys (fetch once, keep a copy)
curl https://api.burnledger.io/.well-known/burnledger-keys -o keys.json
# Verify, fully offline
npx burnledger check --cert certificate.json --keys keys.jsonWith the Python SDK (pip install burnledger) the command is burnledger check …. Add --online --api-url https://api.burnledger.io to also check current revocation status.
Programmatic verification uses the same verifier the CLI wraps; it ships in both the TypeScript and Python packages.
What gets checked
- Two Ed25519 signatures, over the attestation (records were present, signed at attestation time) and the verification record (binding every system's identity, query, both counts and both timestamps to the subject and issuance time), checked against the published keys rather than the key embedded in the file.
- Canonical bytes: signatures are checked over canonical JSON, so a verification record altered by even one byte fails.
- Coverage: every attested system must be verified exactly once, and no unattested system may appear. A partial deletion cannot validate as a complete one.
- Transparency inclusion: the RFC 6962 Merkle proof from the verification record's leaf to a signed tree head, placing the verification record in the public log.
The public log, for auditors
The transparency log is readable by anyone, no authentication. Every verification record is a leaf; the log is append-only; its head is signed.
| Endpoint | Returns |
|---|---|
| GET /v1/log/head | The current signed tree head: tree_size, root_hash, timestamp, signature. |
| GET /v1/log/entry/{index} | One leaf: entry_type, certificate_id, leaf hash, appended_at. |
| GET /v1/log/entries?start=N&end=M | A range of leaves. |
| GET /v1/log/proof/inclusion?index=N&tree_size=M | The Merkle audit path proving leaf N is in the tree of size M. |
| GET /v1/log/proof/consistency?old_size=N&new_size=M | Proof that the tree of size M is an append-only extension of the tree of size N. |
| GET /.well-known/burnledger-keys | The published signing keys: key_id, public_key, key_status. |
| GET /v1/verification records/{id}/status | A signed statement of the verification record's current status (ACTIVE or REVOKED) with its own validity window. |
These endpoints are served from api.burnledger.io and mirrored on this origin — the links above work directly.
Holding us to the log
The log's guarantees are only as good as someone watching it. You can be that someone with two requests:
- Fetch the signed head today and record it.
- Any time later, fetch the head again and ask for
/v1/log/proof/consistency?old_size=…&new_size=…between the two. If the proof verifies, nothing you saw before has been altered or removed. If it doesn't, you hold cryptographic evidence of tampering, signed by us.
That is the same discipline Verification Record Transparency imposes on the web's certificate authorities, and it works on us for the same reason: we signed both heads.
Revocation
A verification record can be revoked after issuance. The current status is public: GET /v1/certificates/{id}/status returns a signed statement, verifiable against the same published keys. Read it strictly:
- Fresh statement,
ACTIVE: the verification record stands. - Fresh statement,
REVOKED: treat it as withdrawn. - No statement, or an expired one — revocation is unknown, and verifiers report it as its own outcome; silence is never "valid".
If BurnLedger disappears
Keep a copy of keys.json next to the verification records you archive. An Ed25519 signature is standard cryptography; the inclusion proof is standard RFC 6962. Any competent engineer with any crypto library can re-implement the checks from the verification record file alone — no BurnLedger service, endpoint, or goodwill required. That is the point.
Next
To understand what each field you're verifying actually asserts, read Verification Record anatomy — including the precise statement of what a verification record does and does not prove.
Common questions
How do I verify a record without a BurnLedger account?
Open burnledger.io/verify and drop the verification record JSON in: every check runs locally in your browser tab, and the only request the page makes on its own is for BurnLedger’s published signing keys. For a fully offline check, install either SDK and run burnledger check against the verification record and a saved copy of those keys — no account, no network, no notice to us that you looked. That last property is deliberate: a verification service that logs who checked which verification record would learn exactly the thing a data subject is trying to keep private. If you want the current revocation status as well, that is a separate request you choose to make, and it sends only the verification record identifier — never the document, never the subject hash, and never anything that would reveal whose record you are asking about.
What does verification actually check?
Four things, in order. Two Ed25519 signatures over canonical JSON bytes — one from the attestation that records were present, one over the verification record binding the whole document together. Coverage: every attested system is verified exactly once and no unattested system appears, so a verification record cannot quietly gain or lose a store between the two measurements. Zero records remaining in every named system. And an RFC 6962 Merkle inclusion proof placing the verification record in the public transparency log under a signed tree head. Optionally, a separately signed status statement answers whether the verification record has since been revoked. A failure in any of the first four is a verification failure; a missing status statement is an open question, not a pass. The verify page renders each of these as a separate row, so a reader can see which specific property held rather than a single green tick standing in for all of them.
Can a verification record still be verified if BurnLedger shuts down?
Yes, and the design assumes it will happen eventually. Keep a copy of the published signing keys alongside the verification records you archive — they are small, and they are the only thing you need from us. Ed25519 signatures and RFC 6962 inclusion proofs are standard, documented cryptography, so any engineer with a common crypto library can re-implement the checks from the verification record alone; the SDKs and the browser verifier are conveniences, not dependencies. The canonical byte layout each signature covers is specified in these docs rather than left to a library’s defaults, precisely so a future reader can reconstruct it. A verification record is meant to outlive the company that issued it, which is why nothing about checking one requires the company to still exist. The transparency log’s signed tree heads are witnessed off-box as well, so the record of what was logged does not rest on a single machine either.