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

17,951

reports under this root

#974,611

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

Confirmed in Bitcoin block #974,611.

Merkle root
9c8b05c1394e024bbcb980b42eec8b683a36e54fc2bf490249c45ae035248258
Reports covered
17951
Sealed
2026-11-05T01:17:19.994Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #974,611

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

Verify it yourself

ots verify -d 9c8b05c1394e024bbcb980b42eec8b683a36e54fc2bf490249c45ae035248258 crawlcheck-2026-11-04.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 17951 digests sealed under this root

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

0008ed2cb850b70744ef0c2ffa0c556423239362e506e0d585bfad5bff790b4b
000adc90a56cd459e6d91ac2aeaa3ba5e4c985ae23b8bb114a05987579da032f
000ccce1946d3d233e86c1e1d704a166c7c40bf7a593e834c3fe0d79ee8b87c6
001435cf186950bbf2285a91b08565b9b1a86646009ace9e584ae653cbff2407
00159e8e6b41a77e1bd9acbe5e6119e93916f3c74d0b5e21e69c3bc4c4385acf
0015ac59bce4c0cb31cc1e4c19548f13ef91be4d7afa9124e658512af8cf4c38
001f8242f7fcb12646ccd055ccc20d10087c036b0455cd9dba092005689ae96b
0025b8773ad43263bc89fdb1620b67120dd955a8a4067157346c059921973235
002a9e45485aa27cf5ff64fad5732d3403f0c45ddfde9a432bff617b1939df68
002ac410e043eaadc77ad8b233f818663294a711f5878792f77f2797a194932e
002c5051dd98ea6f6a3e5d9e37ee1b437871531ee1c993d50543f45af14ceaa8
003052cda7d3994921550eceeea76335589e130e036ae2afbba3d3415b3fd1fa
0031594b1c693a213be359adf3d9990f2950235d192786664a73a913a01f7f31
003205ad3efeb2da7bf9d63f274c5d187c889f4527de1b0ca589c775b8846f9e
003317f5935f20755f0f385b4b7b8d2d489b11b1346907edcfad75efe19a7e21
003545fe38511b56fb19d189be8b68a8fd0c2e06a8afdb25170faef62fb2c330
0038bb9edf294395e049d11f2e099f778ee139d6a906abaccfcfdfd4b16d7154
003c12984c9ed993d7e26d2a600923e3bd7fbe404c7e18e830836d0b0aa6bf3b
003d8aff22078400625089aca4271fd4430c64a3dc61ce44caa733b580fbf99e
0041e8b6bc4b514ebb3bf468bd94ed82e9eb540ccb727754d3f2d37a6a033194

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.