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

11,684

reports under this root

#974,200

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

Confirmed in Bitcoin block #974,200.

Merkle root
58157da0daeb58bc3d19c4a1f0e1708d7210a881276079ad391fcf503bc8522a
Reports covered
11684
Sealed
2026-11-02T01:17:44.415Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #974,200

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

Verify it yourself

ots verify -d 58157da0daeb58bc3d19c4a1f0e1708d7210a881276079ad391fcf503bc8522a crawlcheck-2026-11-01.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 11684 digests sealed under this root

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

0007bb0e5fb9485c29ddeb546f632869bf5b86a0b2f1868688bb7041982817d4
00093b7861c216a052d665136495a1d759a9b57ee9f42f9a1180d14cbe7c1937
000b87fe73a6bbcaeaa4a9d0fd82722a65c4efa50ccd9e5f9400b3a448df8bcd
0014058a6ce1a5cf0998752e2830216022428896c75a5386071a79a8ce5aa2c4
00148abb23bce1eedf01fce8bd9d920efe34630a81b0db08c0b194a5e67385b9
0017baccc5611b629e0d408314ce7302fccaa8a28e7f2c37771076979c8dbd1b
001f75b716d3aeb490534fd1784ff42f6d81dccd2cc2d953eecab4f916158da0
0025173ed1b99387b0b6819d7f5edd61ceed6c5035110d6b77f8f9e35158d510
0026a61d2570bf8446adbd103b0e92dcd77d4b649fd85845ce2994c265314d1f
00320036c8c4d2dc174413f26a0c84b451c1ed6e9eba07dc3986b8d0a9e1b473
00323acca43809ee7e9c5e34ee11ddad7a9913fca060a22eccaf1e08594578e1
003c86974d5dff297b44ee7ed59cc7405ffe4432afdc07ad88464fd4d0752495
004014addf9cd1bb25c47579290c12c3a4350d6352b8335caa19c94c9e368d24
0042b78a90ba5001794b653c1240478f981792c67903438ecafa34ef09cc02ca
0042eca32f73bd557a8ec8ab25c404cf2692ea89d25af345c3dbd659c5da3403
0046711d0db944ff61d4dc06556142640f7a456936837e30466636c4178ba5e3
00703b76286a6f7969921e97ea75015bd7f2564fac96f5d268c712762cae2e57
0074328c7381ea1a2cdb9fbecce2a6c3e181237d263847b75c581da46add7d8e
0075fe8b71116b23507934888cbb6eca1f359dadf0fb497f65d80c1225e49807
00793b4ba6da959d9087bf014b65a419757efb63cb66bd78f30642d1fd3f4d0f

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.