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

reports under this root

#972,551

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

Confirmed in Bitcoin block #972,551.

Merkle root
5602ed12b151f5ac4aa48bbb393bcef10dde02b2d3dbbb8deab700e02cf4668d
Reports covered
1701
Sealed
2026-10-22T01:17:36.432Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #972,551

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

Verify it yourself

ots verify -d 5602ed12b151f5ac4aa48bbb393bcef10dde02b2d3dbbb8deab700e02cf4668d crawlcheck-2026-10-21.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 1701 digests sealed under this root

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

0020f8603973393cf154eaec84af2e441db3b20c24dd4b2d62a2d434e3df562c
006a33b8ab4d7f4bb61be6b84d6265a46d5f47e7f8e2e43d129a2ccbe260767d
007765e8fbb10359b1771185ec554cad22dd250ed6a5e896a0a98e72afe7a895
00afc65a702cdc41777b2473dd320f72f714c0574f68a1776af73e80f9b5bd24
00c9b57ec3147864b367ea3341f893b9f1ad73fccfc7cae479152531bfe0a45e
00f0c9257fc508a4579625a67d2d852ae40236155a32c339b9b2cc680a4ab9dc
00ff4fc3c07b671f2c4b4c31697d338e975c5e574eefad608ddb6ef5a6d9a1b5
011fd0557061707a49b676f407c8d79be3437c30ae9727934aa6cde00b0f1029
016b8cd579c48ae7706cd8f2ac8ce02354d54266da983b04db454ac2fb52c7f2
0170dc52f907142ac210e3b9ec5e49f41bbe8d179cbe68dfbdcd43cbd7f1dcb5
01bfa71c25718ff84a1ee94ac6a2aeb8135bcf4a84a1bbc77f18a8430a31ccf0
01c48f4b7115bbbc0ebd35e36671fba57845d6c6271a7c5c691b1377fe3b8c94
020ea8d86c2279558dc0b7dca47d6819c661b422757327b2ff2cf47b2e853d22
0228dba85551b2f5bce9e6a953c36dd7e692833ed71c757dd2686c727c83e7a8
023faab5dae977425970f970557e93f3afc2aa7f593f09bcd4626f86057bb566
026c043bc7470c526c76eb859215a13e466b76ba191faf07cd964c8c55e318eb
02aa87e43f3aea5ed64d4c86984579463069605946449c5a0abd7ac11abee169
02eb70d0a398819eb60441c2622ff7b122fa9e43bdcc53dcf65ba4c13c916e85
02efd99048592aab4639dc20212a9f71e56944d1ac3a8db8f7f4de744bf0a9e3
030079c353626a33a05f104d8e6c1b245065b073bc28ac2d3ab51607861ad32e

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.