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

24,163

reports under this root

#975,507

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-11-11

Confirmed in Bitcoin block #975,507.

Merkle root
4bd43e9681c443e93e93e56ca92cdb7879cf5846a569b99415cad71c54e79857
Reports covered
24163
Sealed
2026-11-12T01:17:15.888Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #975,507

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

Verify it yourself

ots verify -d 4bd43e9681c443e93e93e56ca92cdb7879cf5846a569b99415cad71c54e79857 crawlcheck-2026-11-11.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 24163 digests sealed under this root

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

0001b3edcc72473b78421337fc2ed847b3027e73ef27aa763d7376e675e2f10c
000a54353fd57c24955b6e04ead40217f8de77fb2fe6a6122591144ba2366164
000c67e5b4b8cf8efaadb1fcaf00bd3e80ad853aecd7d8ad3084c767d243d3b8
0011661a650977b265e88584936b6bc4b31676b9c8867db9d326d75f4276b174
0016d8c058866b6b48aa22a364c5777ca15fe6f15669d5fcc690a12005c5d965
0016fac59d06ae9790d3b435959446dc778674698a1b0c2536ba833711df4fa7
001c124da0f85f858abfd3e8881c7b82389e2bd13c5ddc37ce3365fa70d88690
001f866dfccb7291389f8f0296184a4c1256592b42f91a703bcdfa3258b15374
0020d5856b45f49598e4b98a2f3089c8279a0f89abcc04d8ba9ac29d874dbc91
00241197aa4d532741579ee2c8e92272a292644c30809cc732ccce8c59864228
00252b925f804e8d48eb0d3fae14a4d0cb58ef4cd69077702ec7dda68075e587
00290e092c4f3dd2a8ed3d9c505e7fbbfacc06579901b233e58302c949486f6a
002aa5fc2026c32d744aaefe52edf500db01b4a949db52d2d2885fbfe567409d
002ef1f8d4b4e1bbed99307d552924672d6054ff5603c32b2ff5d784d0b42e9b
003001f5dba5c1f896cf7f22d6751b948618a6c2f77d45fdd6f47fd7ab274508
003297ff27fc959935a1ac82af69888a887933ac0164ecf0a50a43df050aca25
00347de5c454744fb439c0659344a87d2636161373cbdf7d103b316f157151ed
004460aeba5395e7e06aeb32e36ccfac5f3f036f45d8a949ee0db5e04bee1cd5
004ad5129f62dbf6c89ee3f404a60308631b8988fc76ece7115e6019e4fa957d
004cb921c1661cd3495239fe74e05112f5ad0f37dbb6adb37d73b7a2ed2ed637

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.