Independent verification — every command below was run against the live registry before this page shipped
Every page on this site says the registry is "verifiable without trusting HashCare." A claim like that is worthless unless a stranger can actually do it. Here is the whole recipe — four commands, no account, no Bitcoin node — and the exact output you should see. If the offline check in step 2 ever fails to match, that is the registry telling on us.
The registry's hashes are public by design (they contain no data). This endpoint returns every anchored fingerprint. It needs no key and no account.
curl -s "https://hashcare.com/api/anchor-root-data" > hashes.json
# → a JSON array of 64-hex strings, one per anchor
The published method: SHA-256 over the newline-joined, ascending-sorted hash list. Check a published day first — every root ships the exact list it commits to, so any date in the registry is checkable offline, forever, by anyone, with no endpoint involved. This is the check that must always hold.
curl -s https://hashcare.com/roots/2026-08-20.hashes.txt | python3 -c \ "import sys,hashlib; print(hashlib.sha256(chr(10).join(sys.stdin.read().split()).encode()).hexdigest())" # 766ae410a0794efa89e88d678b78114c4da11be3f21226cc24d3ff95c085d37d — equals root_sha256 in 2026-08-20.json # We publish the file with no trailing newline, so a plain `shasum -a 256` of it matches too, and CI asserts # that. But a stray newline would only break the shortcut, never this recompute. curl -s https://hashcare.com/roots/index.json # every published date, its anchor count, and whether its hash list is published
The live endpoint is a different thing, and it is expected to differ. anchor_root_data returns the registry as it is right now; latest.json is the snapshot taken at that morning's countersign. The moment anyone anchors a document the live list runs ahead of the published one and the two roots stop matching — by design, not by fault. Compare them when you want to see what has been anchored since the last root was published: the count difference is the answer.
python3 -c "import json,hashlib; h=json.load(open('hashes.json')); \
print(len(h), hashlib.sha256('\n'.join(sorted(h)).encode()).hexdigest())"
# yours ↑ (the registry right now) vs ours ↓ (this morning's published snapshot)
curl -s https://hashcare.com/roots/latest.json
# Equal only if nothing has been anchored since generated_at. A difference here is the registry
# growing during a working day — it is not a failed check. The offline check above is the one
# that tells on us if it ever fails.
Each day's root has an OpenTimestamps proof file. ots info reads it without contacting anyone and lists the Bitcoin block(s) that attest it. (Install once: pip install opentimestamps-client.)
curl -s -O https://hashcare.com/roots/2026-08-17.ots # any date listed in /roots/index.json ots info 2026-08-17.ots # … verify BitcoinBlockHeaderAttestation(962951) # # Bitcoin block merkle root 393eb7f6… # A block number = the root existed before that block was mined. "PendingAttestation" lines are extra # calendars still upgrading; one BitcoinBlockHeaderAttestation is sufficient. Very recent days may show # only pending — Bitcoin confirmation typically lands within a day.
Confirmed independently on 2026-09-09: Bitcoin block 962951 carries merkle root 393eb7f67f87376547f3156fe9ae15e192211b013501ad94d4a81c27ba665625, mined 2026-08-17 22:06:13 UTC — checked against a public explorer, not against us. That is the end of the chain: the 2026-08-17 root existed before that block, and no party involved in this registry can alter a mined Bitcoin block. Check it yourself at mempool.space or any explorer you prefer.
Reconstruct the raw root bytes from the published JSON, then run verify with --no-bitcoin. It prints exactly what to check on any public block explorer.
curl -s https://hashcare.com/roots/2026-08-17.json | python3 -c \
"import json,sys; open('root.bin','wb').write(bytes.fromhex(json.load(sys.stdin)['root_sha256']))"
ots --no-bitcoin verify -f root.bin 2026-08-17.ots
# To verify manually, check that Bitcoin block 962956 has merkleroot 0ddf186f…
# Look up block 962956 on mempool.space or blockstream.info; if the merkle root matches, the proof holds —
# and nothing in this chain required trusting HashCare, its database, or this page.
generated_at, and the Bitcoin attestation proves that root existed before a specific block — so for every date that publishes its hash list, no anchor can be back-dated or silently removed without the recomputation failing. Roots published before hashes.txt shipped (see hash_list in index.json) commit to a set you can no longer reconstruct from here — their Bitcoin attestation still stands, but you have to take the membership list on our word. It does not prove what any fingerprint means: a hash proves a document existed unchanged, not that its contents are true, and never that a clinical event physically happened. If we ever changed the method, the roots would stop recomputing and this page would be the first place it showed. The ots tool needs internet certificates; on some Python installs set SSL_CERT_FILE to your certifi bundle. Everything above was executed against the live registry on the day this page shipped — the outputs shown are real.