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.

91

sealed days

232

reports under this root

#967,918

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-09-20

Confirmed in Bitcoin block #967,918.

Merkle root
fb4cba366b09731b434d29b35007e7631531f2f95a7efe114a8383943383a26b
Reports covered
232
Sealed
2026-09-21T01:17:24.646Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #967,918

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

Verify it yourself

ots verify -d fb4cba366b09731b434d29b35007e7631531f2f95a7efe114a8383943383a26b crawlcheck-2026-09-20.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

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

The 232 digests sealed under this root

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

007641ac86739573c0289aefa1352e9a43786c0b8d97e99779b38898df2dcbfe
04aa4f71b480b2787d0b5db0048aa0b92936808fe8c7bc8ade5fd2714b0c011a
053cd43c09238164373c40e7d4bf9731c500600474fcc33fff5c5d6770eea181
05b486e3b958b6f906b9618c84ba768de18ac8cdccdd8d00b76ef9d8145baf97
06516ad89ecea7e44352ca73f5574e113609d4df764d65c3b7ae688b99e5e909
08b3798551e32c0d5818f8e86dd6d9697c575bab263c263a9939e64dc071615b
08e1cdd417cf68c524eb067d907f41a7d23e475a5936009bc77bf48e057f7b07
09e9e97588f937aae5b3d70139d9244d7ce749636f859da384fc4751ef8cbdb6
0ada95325e3921a0cf09c1aedb2f4359a43ad4d6215feb422fa769043e1d0a48
0b881f1252b7b2718e988ab811ab3bfe26b88f110a6b2fd3e2df1cbc69d0391d
0bf04fcfbee3c1d47fc8014da42bf414ccb3b420384a58af168868775f94eacf
0dc39ed6d0c04e511f00063d2f9c2e7312385c087598744b417c98906f6e2e7e
0dd9e461df622656b007ceb0b44a0422716b2c24d5daa200bd9d37dcaa119a59
0fec875bdda1cafd53dd89a021713348aa2479f9f084ac434c6265ea6ac84b5a
114e81e6c8f247ba67ab977aea4ea7509b624bc7bcb3c35ec3db366bef09186d
117678cafa2d3384c57b0b7c30c09e1b9129d960b72c2ac230368f2990dc059c
11b7aafdc069c840f8243c8c72db8b658e55e39147730de517df8c1fe3453da2
12870ee482e411a367c68640339a5f2e6c981e1420fe7eeeb8d6ae4858989edc
14f4c5316b0c2ea9a9adbbc9d0537d078ad78f1fa3719dbfdcaedf72f4802daa
1518a5a0a980b4c5ff548d867de0cd8c1991670a6dcecb04ee13d8d31f048819

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.