Paste a BurnLedger verification record below. This page runs the MIT-licensed verifier in your browser — two Ed25519 signatures, then the RFC 6962 inclusion proof — against our published signing keys. The verification record never leaves this tab. Want the details of what each check asserts? Read how verification works.
You scanned a verification record.
Verification record ID
You can look this verification record up to see whether it is still active or has been revoked. That sends only the ID above to burnledger.io — the same trade a browser makes when it checks a TLS certificate. For a complete, independent check that sends nothing at all, paste the verification record’s JSON below instead.
The Ed25519 public keys come from /.well-known/burnledger-keys — the only network request this page makes. The matching private key is generated and held inside an AWS Nitro Enclave, released to it by a KMS policy that admits only that measured image — that last part is how we run our infrastructure, not something this page can check for you. What gets checked here is the signature against the published key.
Two Ed25519 signatures on the verification record are recomputed and checked in your browser: the attestation (records were present at attestation time) and the verification record signature that binds the attestation to the verified-absent counts. When the verification record carries an inclusion proof, the signature on the signed tree head is checked as well. Alter one byte and the check fails. Coverage is checked alongside them: every attested system must be verified exactly once and no unattested system may appear, so a document cannot quietly gain or lose a store between the two measurements. The record count in each named system must be zero, and the RFC 6962 inclusion proof must place the verification record in the public transparency log under a signed tree head. Revocation is the one thing a paste alone cannot settle — if the document carries a signed status statement it is verified here too, and otherwise the page says so rather than implying the question was asked.
The verification record carries a signed tree head and a Merkle inclusion proof from our append-only transparency log. We can't quietly revoke, backdate, or deny a verification record the log already holds.
A verifier we host is still us. The same checks run anywhere, offline, with nothing from BurnLedger but the public keys.
Read the verifier this page runs# the published signing keys
curl -s https://api.burnledger.io/.well-known/burnledger-keys | jq .data > keys.json
# offline verification — exit 0 means valid
npx burnledger check --cert certificate.json --keys keys.json