Verify a bundle yourself

The verifier is free and MIT-licensed. Verifying is never paywalled: anyone holding an evidence bundle can check it on their own machine, with no network, no account and no code from the system that produced it.

Why you can rely on it

The verifier imports neither the core package nor the commercial one, and no network module. That rule is a source scan that runs as the first CI step, so it cannot quietly lapse. It reimplements canonicalization, the chain walk, signature checking and RFC 3161 timestamp checking from the specifications, and a cross-implementation test keeps it in byte-for-byte agreement with the code that writes receipts.

Run it from source

The packages are not published yet, so run the verifier from a source checkout. Every command runs from the repository root, in order, with no edits. Step 3 also needs one file you download from DigiCert.

Clone and build
You need Node 22.5.0 or later and pnpm 11 (corepack enable provides the pinned version). The build compiles each package into the files the commands below load.
```
git clone https://github.com/JaredKlopstein/lacre.git
cd lacre
pnpm install
pnpm run build
```
Verify a real anchored bundle
The repository ships a genuine bundle of 3 receipts whose chain head was timestamped by DigiCert’s production RFC 3161 authority. This exits 0 with VERIFIED / ANCHORED / AUTHORITY NOT IN YOUR TRUST LIST: the timestamp is sound, but you have not yet said you trust the authority that issued it.
```
node packages/verifier/bin/lacre-verify.mjs examples/sample-evidence/evidence.json
```
Trust the authority yourself
Trust has to come from you, not from the bundle, because anyone can embed a self-signed root. The certificate at the top of the token is DigiCert Trusted Root G4 cross-signed by DigiCert Assured ID Root CA, so do not pin its fingerprint: it comes from the bundle. Download the root DigiCert publishes, DigiCert Trusted Root G4 in PEM form, save it in the repository root as DigiCertTrustedRootG4.crt.pem, and pass it with --trust. The verdict becomes VERIFIED / ANCHORED, the anchor reports trusted by you: yes, and the verifier prints your root’s fingerprint as your anchor. It should be 552f7bdcf1a7af9e6ce672017f4f12abf77240c78e761ac203d1d9d20ac89988. Confirm that on DigiCert’s own list of root certificates rather than taking it from this page.
```
node packages/verifier/bin/lacre-verify.mjs examples/sample-evidence/evidence.json \
  --trust DigiCertTrustedRootG4.crt.pem
```

Add --json to either verifier command for a machine-readable verdict. The getting-started guide also covers recording and verifying a receipt of your own.

What the verdict means

The first line of the output is the verdict. The PDF and HTML reports use the same names.

Verdict	Exit	You can conclude	You cannot conclude
`VERIFIED / ANCHORED`	0	The receipts up to the anchored position have not been changed since the anchor time, as attested by a timestamp authority you chose to trust.	That the actions happened as recorded, that every action was recorded, or anything about the period before the anchor time. Receipts after the anchored position are not covered, and the verifier warns about them.
`VERIFIED / ANCHORED / AUTHORITY NOT IN YOUR TRUST LIST`	0, or 1 with --require-trusted	That the receipts are internally consistent and the timestamp token is mathematically sound. This is what every first run shows.	Anything that relies on the timestamp. Nothing yet shows who issued it, and a bundle can carry a timestamp from an authority its producer set up. Pass the authority’s root with --trust and run it again.
`VERIFIED / NOT ANCHORED`	0, or 1 with --require-trusted	That the receipts are internally consistent and correctly signed by the keys in the bundle.	That they were not altered or rebuilt. Whoever held the chain could have produced this record at any time. It is self-attested.
`VERIFICATION FAILED`	1	That the receipts the verifier names were altered, removed, reordered or wrongly signed after they were written. It lists the ranges that are still provably intact.	That the intact ranges can be relied on without further enquiry. Ask whoever produced the bundle for the original.
`VERIFICATION FAILED / FORGERY DETECTED`	1	That the history was altered after it was anchored: the receipts no longer produce the chain head the authority timestamped. Treat the bundle as unreliable.	Which version is the original, from this bundle alone. Request the original from whoever produced it.

An unreadable bundle or an unknown or malformed option exits 2 with a message and no verdict (a JSON error under --json).

Compare the anchor time with the actions

Always compare the anchor time with the dates of the actions you are auditing. An anchor proves the record existed, unchanged, at the anchor time. It says nothing about what happened to the record before then: until that moment, whoever held the chain could have rewritten it. The verifier prints the receipt dates (dated) and the anchor time (attested time) so you can compare them, and warns when the gap is longer than a day.

Exit 0 is not the same as trusted

Exit 0 without an authority you trust does not establish who issued the timestamp. A bundle anchored by an authority its producer set up still verifies and exits 0, as VERIFIED / ANCHORED / AUTHORITY NOT IN YOUR TRUST LIST. In a script or CI gate, run the step 3 command with --require-trusted added. It then exits 1 unless an anchor is from an authority you passed with --trust.

What a verified bundle does not tell you

It does not tell you that the actions really happened (receipts are what the agents chose to record about themselves), that every action was recorded, or who controls the signing keys. The public keys come from the bundle itself, so ask whoever produced it to show you, separately, which system holds each key. See Security for what a verified chain does and does not prove.