CrawlCheck
Proof

Proof an agent can check without trusting us.

An agent that acts on what CrawlCheck measured should not have to take our word for it. Every report is fingerprinted and each day anchored to Bitcoin; every answer an agent acts on is signed; every signed answer is entered in a log that a witness we run on GitHub, outside our servers, re-checks. Each of the three is checked on the reader’s own machine.

Proves

A report with this digest existed in exactly this form by that day, and has not been edited since.

Does not prove

That the measurement was correct. Only the first claim can be settled by mathematics.

90

sealed days

1,745

reports under this root

#973,762

bitcoin block

Three proofs

What each record proves, and how to check it

Each check runs on the reader’s own machine, from files that are published and can be kept.

1 · Reports

Sealed and anchored to Bitcoin

Each report’s measurements are hashed; each day’s hashes become one root, committed to a Bitcoin block through OpenTimestamps.

Proves the report existed in exactly this form by that day.

The latest sealHow it is built

2 · Answers

Signed with Ed25519

Every Resolve answer an agent receives before it reads, cites, connects or transacts carries a signature over its canonical content.

Proves the answer came from CrawlCheck and was not altered in transit or afterwards.

The signing keysThe offline verifierWhat an answer holds

3 · History

Logged, chained and witnessed

Every signed answer names its leaf in an append-only Merkle log. Each signed tree head chains to the one before, and a witness we run on GitHub, outside our servers, re-checks and co-signs it. It is our own workflow: it proves the log was not rewritten on our servers, not that an independent party checked it.

Proves an answer was not rewritten or removed after it was logged.

The log headThe latest witness

Method

How a report becomes a proof

No wallet, no fee, no key held by us. The proof is a file, not a coin.

1Reportmeasurements only2SHA-256one digest3Merkle rootone per day4OpenTimestampstwo calendars5Bitcoin blockpermanent
  1. 1

    Measurements only

    Host, timestamp, section scores, every path and status fetched, every crawler identity and what it received, the citation state. Wording and layout are excluded, so an editorial change never breaks a proof.

  2. 2

    One digest

    Canonicalised with sorted keys and hashed with SHA-256.

  3. 3

    One root a day

    Digests sorted and folded into a Merkle tree: parent = SHA256(left || right), an odd node paired with itself. Arrival order cannot change the root.

  4. 4

    Anchored

    The root goes to the OpenTimestamps calendars, which commit it into a Bitcoin transaction.

The seal

2026-10-29

Confirmed in Bitcoin block #973,762.

Merkle root
15d05ded55ce6851e7a66be0258bf8763db4e05cdbd5afdea5282c252928ff23
Reports covered
1745
Sealed
2026-10-30T01:17:27.491Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #973,762

Download the .ots proofOne report’s receipt as a single file →

Verify it yourself

ots verify -d 15d05ded55ce6851e7a66be0258bf8763db4e05cdbd5afdea5282c252928ff23 crawlcheck-2026-10-29.ots

The reference client checks the file against a Bitcoin node or a public calendar. No CrawlCheck server is needed, or trusted. A fresh seal reads pending confirmation until the next Bitcoin transaction confirms; ots upgrade then stores the block attestation in the file for good.

Ledger

Every sealed day

90 days anchored. Each links to its own root and proof file. Days are sealed once and never recomputed.

The 1745 digests sealed under this root

All 1,745 digests as plain text, one per line; the first 20:

000a7a9c217b3ba52c19d746850abc6a21c318c72f5e5d41613020a038fbd657
00107a5354ed314c94fc8e2081e69e2a3d691a9dc8194a3a4d374f9690f65f65
004cf573e1b3691d779175363643e7633dfa715be8b169bc05ac240e60f404ca
0051e40ebc8f9e774f6e8ad4acbf08916db11ca7d8a32bbef25eb323ac8c9260
0056abbe8661dbbc0c987b8bd56d202e68a0c06d5db099f1a4e93a1702d4a49a
007e94dfb8416d9cd7e4a4998de19b5360b3742fa6a7f5abf929e5534409ace6
008c77d56b6d82b445e7df429894b0cc7870da516144b460897a8606d2156da6
009a4a2de6ce8da611eaeb0a98726454a62ea39a43b2c98447d713ecb80a2736
00b5bbe03759d6f83a98311f54232625b721cae8e3e8f4a4a6d051f8bce98df9
00ba34e338bed713ddbd62c80ca5e44ae478f9d2f29efc4938a063aaf12ac3c9
017c96807b3a803659feaa390ef8416853b7bd5967828e1e50daea8b832478c3
01a3bfdecd5ff63136924488e632610df73c0900efdb7d031c8425a44896a339
01b847828c2890ee35e014dd693ef9d79509fdd91bf76c922b5bdcc72069a38b
01ccf846e813023d801f8f51807849e8605b8d6b71002afb5764479c7b5970a8
01d159c6d33c9523e997147f44ceb4c4877ae9e8a11dbd829f0c0dafc31d38f7
01db48443f62e647dab3ab4bde58beb499f4ca95bb11ae81118931bc755cbf09
01dfdf4da4c35deac2d08942b324848186fa74618b8b2d6056167d989dbc299a
01f70c16fbc3ba530038d43424bb0fe9c9b9ff5669b187cf84bcbb489a9a9179
02028d2a87f0c519cbf05c5c757efce71c7a73ba5c9f2eab372f027058e000bb
020d6785d57f19a5e022ca128828aec0c5d5c5ddae59d922b9aee8496937dbfa

Questions about this page

QWhat does the Bitcoin anchor prove?
That a report with exactly this digest existed no later than the anchored block, and that it has not been edited since. It is a proof about time and integrity, not about correctness.
QHow do I verify a report myself?
Download the day’s .ots proof from this page, recompute the report digest from its JSON record, and verify the proof with the OpenTimestamps client against a Bitcoin node or public calendar. No CrawlCheck server is needed for the check.
QWhy exclude wording and layout from the hash?
So an editorial change never invalidates a measurement. Only the measured fields are hashed; the words around them can be improved without the proof breaking.
QWhich days are anchored?
Every sealed day is listed on this page with its digest and proof file. Days are sealed once, after they end, and never recomputed. A day sealed within the last day or so reads as pending in the reference client: the calendar holds the commitment, and the Bitcoin block confirming it is usually mined within 24 hours. The proof file here is upgraded to carry that block header once it exists, so a pending file is a proof waiting on a block, not a missing seal.