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

270

reports under this root

#967,779

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

Confirmed in Bitcoin block #967,779.

Merkle root
3eb29d3fcf44ef820eb2146139637de30a6ac836f522866bf5694c670990f4e0
Reports covered
270
Sealed
2026-09-20T01:17:25.827Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #967,779

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

Verify it yourself

ots verify -d 3eb29d3fcf44ef820eb2146139637de30a6ac836f522866bf5694c670990f4e0 crawlcheck-2026-09-19.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 270 digests sealed under this root

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

019e24c746163320d3c9140f33c6fe895bf6cedc9bd296f2b602333a4a131efb
03f6a58d43c98b367d59de01af086b4ea285b26b7b9719ff9a70055b7f11470e
0416b654844429b53369d5bbf0b832f9441d7a4ea73c6eb8ccde6332929e61b6
0520ec0dbd17db8c00a56da4f78aa7da55057178a7699a0dc3b10f642ee83ff7
05e8ab91f3d311711a7fa47d479e7fda7020c88d916e1468e7c37f17342ec5e2
066415f9e0fb213ab1f93990044514204e9a757c1415843f70fa7ab3ad36b292
06c9d368766a796977d036d4a0b553ac2a1c7e5f88796b62786a9c70ccc226fb
0720992d8c15f3267d8e6118509e00f12605d598167c258442313804a9b53af7
07269edcd973357506ccb977c00dcd09a72ae6c403b1653fbc47b0a13d1d16df
08718d284610379e190d8a9bf422ca3f276b3ed28b2e78ee102ef070edb43e80
088cd9268006597c3373211b37843da53e240befe36e8039ad5f4c5f7c70b4eb
0aeff44cd188aadc002191a6a02140f55737488bcfef8d360a69040cdbf41604
0b8a08bfc0b03e3e63378bbded36aec43d2c865980bb151f0f0eda64ea0559c8
0b9f9be640bcd418f3b190fad0fa5aeae9c10bed2f18bab0541b3efe1949eaea
0de002e9b66f8c1ed94095514aba246255f2a5363297083d8d50ee614acbf02e
0ded0778b0dad5f083ff871075905a40fc38dc5edf37a51a2daa7d27dadfa099
0e313b8e7a1382c96740313cdfc8b48eeae4e6c7004b7802740c68dbd4e60f79
0eae4580762285ca21cc1372d400a35086f1fa61c2cef36fa2c0635038d2f6b1
0eda14990363a870bae98a582b94f8662aa76ecd7ebad594c8883ecac6448f59
0f6dc5c615e9eab43bf7a3c46e2230eb24fc5eb4b573afc89eb7ab446d9361e5

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.