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

1,728

reports under this root

#973,625

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

Confirmed in Bitcoin block #973,625.

Merkle root
c03ffc9fa70803b323363b2418ff1931088ed5a06ca1c5d5832a9735a4ae141a
Reports covered
1728
Sealed
2026-10-29T01:24:56.104Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #973,625

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

Verify it yourself

ots verify -d c03ffc9fa70803b323363b2418ff1931088ed5a06ca1c5d5832a9735a4ae141a crawlcheck-2026-10-28.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 1728 digests sealed under this root

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

00576d428ed70577433238452fc542a926fbe56f8c7f8890148120574201f816
007a7928acbfde5400c51bb0af48643a9d3d438a2060eac7c1a127e00c82abe2
00a018f177f6cca5df9bd8592da53eec7ea644f30e322a022adfe82fd67cf866
00ab0b69e4955d64180167bfc10202f626a712532e9282c2a06bcdec3b79da77
00c4b4758622f81c2e4841d69067e5ae3821a7a322bd14aa7856eb228f82d506
00c933dc27acbca911f39fd2279b4067cc976c046369382eb68cf90213ca1cba
00cc1796c9aa9ad009c498cd7e9356137018ac175507221c8ac9174eebaba5b4
00dcc703bc5cf95ccd0ee0a9c2703b8bc6d5beb87f943aacbd35d0e141cdba86
00f9eae961408d54915ab97ccdb8222e6d82483dafd316e99f28fed58aed1140
01001f79489212f899a6d5c0c67a40c2565dcf9a631604d2eec407fffb9bd5ef
01364dc1779c04a753ef7b17045941f72a989172928ad1ecd578d705ea724401
017b6bcf49fb3e6348f392432be4e79c2d599ab73e63dffbb279b681c7bae9a2
017bb5f7d1befb69684aabb0a4f4066a29ffda24c69883f0f058b877ff46b537
018611c590563f2cecaaa0a186d8f6b213242ae888014e7ffe6d63159c557aaf
018b0bc6eb639d07c2fb8137985380651b04539354f6f62e9016dfd5ccf1ca3c
01a00c00bc0639aa265d4ea95f57e237735bd726a5142d611326575e219a4d06
01aa923c877c2d78056a467966f6c45f4d571176b2435661b81c8a7b9a2dd96f
01b6f6881be455823941b8d305b09d7f7c8f79a528f99000fea6552b229350d2
01d0fda297a98fafa7019cd0c3bd3b70454cb5bd7ae28e64918726af25de4663
01e1182763deb39ea71696e8729bce96ef93e771e2f5c4b41b1291b81aa9a17c

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.