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

16,465

reports under this root

#974,744

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

Confirmed in Bitcoin block #974,744.

Merkle root
7984f4e5fd21da06ec434f2c939e20287de23089d6943df978fbb5dcb9faa8d4
Reports covered
16465
Sealed
2026-11-06T01:17:21.314Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #974,744

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

Verify it yourself

ots verify -d 7984f4e5fd21da06ec434f2c939e20287de23089d6943df978fbb5dcb9faa8d4 crawlcheck-2026-11-05.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 16465 digests sealed under this root

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

0002b3c7d347b1f4d9fadc9288ab99b5a8748e363d7383b4cc730b46b6a0d74d
00032e0eda3af4b5c66b0877ff62d90ce41cdaad02d286bcf47b589f76802670
000bdfe923af3cee28b945ad0feec50165d6f485b1bdca5363ba8ae0dfa1cd57
001adc450cb6f7723b0e12d342e999e67b9b83cb01601519c320d9dd7d9a1df5
001da0703be3d73017c40faaa2121133e94bf59c55f021e4c0f1961710defd36
001f4badc9441ce137b5f3fec85aa24a8a75672fa68e8a3cfce44ad8e4880686
001f550bfeb518e994b73c779de4defbd1ef960685ae4653f16f7255a6aa082c
0020193f9950fc4a1fe8a034274e8a6e2a76c00f791fa3e200690b0d1ba77cc0
0024effd4eee0e6292bf85f3fa5690024eedcbd2784f60d3e0a6aa4b4418eaa1
003a9d9c413efa6828e29dfd9e5565a6534465f79b9ee72dcefdb816cd15da10
003ec149f9a45974637ad68a65d19ec7502f6c61178bd67cf7886903de37f8d8
004162ed7ec5b159028063a2d4a3aa2ad400af605356020d0f989859d300f801
0043408f0de93ef46d4430e5df9f1947a2a1c9e5a2ddaae1060b376bc9e7688c
004598984bc72432a3954de43e3ef67c3e6f432cd00b1832972ef58ece068669
0046e74fbe6dfc69a25f6ddeaea7cb41d54e8beac709888efe81057293ba5ced
006041cb77f8a715b946e9e3b7b581c37dd0314c0239ab6e27b32544490ef9d2
00652591f4b567627c4e81abba154824316c5ca8b1bbcbd2a1811a6813a98b63
00659f6050b82ac98846d59226d4e32947980949a5c480abdf33dd09fe36a210
0067b252dd06166b6f0647f7865d49dd5635fe940c6e17c4fd55ad995a63292b
006c2f62877a5105993356ab488e8e90aaf80af78742dfe2748b40275b71b773

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.