Three commands, from an empty directory on a machine that has never touched AERE. The tool is ours and short enough to read; by default it reads the chain through our public endpoint (point it at your own node to remove that), and it checks the published key manifests, not who holds the keys (see below). (Corrected 2026-10-27: this sentence said that the commands use nothing of ours except the chain itself.)
Run it
curl -O https://aere.network/tools/verify-anchor.mjs \
-O https://aere.network/tools/mpt.mjs \
-O https://aere.network/tools/falcon512.mjs \
-O https://aere.network/tools/registry-v3.mjs \
-O https://aere.network/tools/package.json && npm install
node verify-anchor.mjsThe 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 and SLH-DSA-SHA2-128s seal against the published validator key manifests. A clean run prints one OK line per anchor and ends with a single VERIFIED line.
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. A Node.js error printed before any line about the chain (for example ERR_PACKAGE_PATH_NOT_EXPORTED or Cannot find package) is not this: the tool did not start, usually because the dependencies were installed without the published package.json (corrected 2026-10-28). |
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 their 32-byte digest, so a certificate that does not match it is refused by a node that validates the header (corrected 2026-10-28: this said the block hash covers the certificates). 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.
Documents are checked differently
The whitepaper is checked differently: every measured figure in it carries the block it was read at, and its version block prints the curl and sha256sum commands that recompute its content hash and page hash. verify-anchor.mjs checks anchor blocks only; verify-proof.mjs (AIP-23), beside it in /tools/, checks a notarized statement and runs verify-anchor.mjs for its finality. (Corrected 2026-10-26: until this date this section said that the same verifier checks the anchoring of the whitepaper.)
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.