Three commands. They use nothing of ours except the chain itself, and they can be run from an empty directory on a machine that has never touched AERE.
Run it
curl -O https://aere.network/tools/verify-anchor.mjs \
-O https://aere.network/tools/falcon512.mjs \
-O https://aere.network/tools/package.json && npm install
node verify-anchor.mjs
The tool reads recent anchor heights from a public endpoint, pulls each header, rebuilds the block hash the way QBFT builds it, recomputes the certificate digest, and verifies every Falcon-512 seal against the validator registry. A clean run prints VERIFIED for each anchor it measured.
What the exit code means
| Code | Meaning |
|---|---|
0 | Verified. Every anchor it measured carried a valid certificate bound under its hash. |
1 | The chain failed the check. This is the one that matters. |
2 | Unmeasured here. The tool could not complete the check on this machine, for example a missing verifier for one scheme. Not a pass and not a failure. |
Exit code 2 exists deliberately. A tool that cannot tell "I checked and it is fine" apart from "I could not check" will report the second as the first, and that is worse than a red result.
What it proves and what it does not
It proves that the certificates published in those headers verify against the registry, and that the block hash covers them. It does not prove that the registry contains the right keys: that is a question about who the validators are, and it is answered on Network operations.
It also, by default, reads the chain through our public endpoint. If you want a check that does not route through a machine we operate, point the tool at your own node. See Run a node.
The same tool checks a document
The whitepaper is anchored to the chain and re-anchored several times a day, and the same verifier checks that anchor. This is not a second mechanism, it is the same one applied to a different pre-image, which is why we publish one tool rather than two.
If it fails
If verify-anchor.mjs exits 1 against the live chain, that is a finding about us, not about your setup, and we would like to hear about it at git.aere.network. We build our own gates so that they can go red; a public verifier that has never been able to fail would not be worth publishing.