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,261

reports under this root

#974,874

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

Confirmed in Bitcoin block #974,874.

Merkle root
fe63652554574533149c6329042e91798f7cf0866e7dbd4e98bfd449209ca7cd
Reports covered
16261
Sealed
2026-11-07T01:17:25.957Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #974,874

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

Verify it yourself

ots verify -d fe63652554574533149c6329042e91798f7cf0866e7dbd4e98bfd449209ca7cd crawlcheck-2026-11-06.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 16261 digests sealed under this root

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

0002c875f79d1cce9c9a687f0336e005e792384b8a2dffb7c2e2870860b01ffb
000b000be4521dc5d06ed5ae9a8b88747104b7f38a33a980c3ffbc1dcbeeb536
001286683810aa48a2af3e18b2fbc29642b5ed9a1bcd5a66a66a083593d4087f
0013035f814f1d56671baeb7df590e94db2d578a9389cabb2a1c0cf2af5ed382
00136e1902c6a8fbea1d51c2014de3ddaf44db758228227d750d1581072ab964
0014eac3ce4e0bb0ecb3bb5b1b06a7075ce4653abc0fe4469123c8990049d1ed
00181c8f5dcb583c3f9b4fd6d6a68e4a69f011d5fcd5e9dfd8b43ace4fbd891f
00189a77c9a12b4342191c8dbd5a869b726d6ef79acf911eb86c984ca84055fe
0022195db3674894c077ea94456836d9aaa220b86e113226c850e7324cb60a29
00243063581b5c6d3b3fbc7b2a71e57388080c3c92f64cdd12bfec49d239ebfb
002bd3eaf688a941a619b7c6b197866cd005cfd54fd5e36f530ce802e523b74a
0037a371ca0d136eac16667c07eee1b11bcc0abec33d0bba4225f8b5475552db
003ca5f42a4d491bf7e7abba5406fbde43c27a2a0d5b4ae0d4ce8d7b3ba0b745
003e99a6b53b9683bb19dcd0dd4153cdcba0ec8671bce1d0e34fced6ed506a28
00440273ae5e66c1d5555b05f122673a3eb1598f35bdd1a4b9afdebb97d905bc
0047ae731766bc170f723004cd71b270c78c80fb849b419b9751478d606337fc
0049ef41774a937939a459eff9ad7e4fb026b1f949c829fa2242ac2c07b5d53e
004afcaac2f9714b78f35855cc171b40a629c00b786f39fba9c16a17765772ce
004c701dfcb364a02c0e7be3e457ae20f3c69b99314026b4fac2f9c4bba8615f
005977a06a4d1181ee79433d3f79a8d0edcd887a29fa9290d46ab0c2ff4ada7b

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.