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

1,879

reports under this root

#973,321

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-10-26

Confirmed in Bitcoin block #973,321.

Merkle root
60565fb40ae567fc266c52f588da8257552c0ce76a5f0d9b32fd4032729fff26
Reports covered
1879
Sealed
2026-10-27T01:18:00.840Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #973,321

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

Verify it yourself

ots verify -d 60565fb40ae567fc266c52f588da8257552c0ce76a5f0d9b32fd4032729fff26 crawlcheck-2026-10-26.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 1879 digests sealed under this root

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

00336b3d95c7e310365b5a5cf46b3068ca05aa9bd2dec50fb247a1040b88b9cd
00380269c054f4d118e4904403a36892af2944c5d153cf03f3a8f74faed20af4
005847d4d2609cc896da16975dd81a2826508e72fe42f76ff98653e46bf40630
006028a9305425f81f57ff61a7c876ab606d37f860c5e7dfecc958b7e4b73419
007e67ef1014870e472a1f4a3eabc72ba5ead1984181ffe799ca84a167ecd14e
0098a8eef5bb480ecab84c1ff7fee6f13ba5c600ea755e592b88a8944555d2b5
00a6a19ec9f4f137324ae970e00d90491b4ca2d8ca3cb22d3f0368e6c3271a6a
00aaf0a4c7553addd7e6cc1c3f2d522288608e90747bcb145072d6426c02d296
00fe0731230d87e78cfa79eb4a99d65c35733f63624e43bd29ef12392df5a69b
013e5b6f91da8b79bb838a9f7971115e96f3ca1726c95a525835847c097cc27a
01aef9dc30106b72eef2e19addfd562376cb3fd78062dfa0288c81b0fb5d5218
01bc134ebfeb5431c7bedb5f7245cfc19cd626d77def441f963ae3b5db2aad34
01ced69c4b1249c7efb4229521f227e5e5f97532b003eb0511e5178b71fe12b9
01cf6fcccbf8fd44090b143100eed3276afb1436c4262c6224de8e69b9950b27
01d5cd9ee1cd6092cd459a99ddf75f988bd0d2fc19a20b0f4cf22ea3ae884588
01ff3335ee6dda325c9783f0c3da01adb7da929c59144c3236a54e6781cb8d40
0237b188ecbfd077ba57c6270217ccb0a0450d4b2d2daa49b21d6c011cae7ae2
02590a1e8e3e81722a193d6d9b0a015841ffd7cc680f036ee367a003c49bcb48
02618f7cdd39f5ad67a9b77b084cc11a6c8c817b366de75e5e83eda8f2f8debd
02870936997f8933614e6219b24742d792eb67db191b9bb5bf3d11df93799fcf

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.