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

558

reports under this root

#967,645

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-09-18

Confirmed in Bitcoin block #967,645.

Merkle root
b0907de64745ce14e091fffddeaf4edd32bfb69cf9872de37c9437ffd516d92d
Reports covered
558
Sealed
2026-09-19T01:17:38.539Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #967,645

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

Verify it yourself

ots verify -d b0907de64745ce14e091fffddeaf4edd32bfb69cf9872de37c9437ffd516d92d crawlcheck-2026-09-18.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 558 digests sealed under this root

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

01e41c57ab2507d90c31c1795d8f6ffc011e90fcf60554c737ddfe1fe290b5fd
029fec0b2dfadf413bbc55b99fb64a73af5a48dbd308a58872a9b5dd3d9424c3
040e8a666c6d4fcadfbc5de4135c1da11d0ff17d79c0b0198e8de606f9b8e3b3
047098b16a8341cee403ed398657936f566ecc7297437836095d680161ffbfba
0490da2197b676af9396394907da577a56774ed6138e32c4617e521f9b667171
05764d11e118262a8ba70f0bed93a2b508ecebc4f7e5320dfab9dd2f3361fcf6
06fe04b6c39dbc1c7a46d7456125ee8c66c14f8445623dd2f6c131cb379935ff
07905612f1717aab1675ded171e64ac4c1714c87bc04c8b009689cd86db92177
0796a427f1740bfa5506c192bca35ad824accc51cda15cab903ea86558cc377c
07e6434696214afc61e2ae36a1c7bf1e25c217af8fc023824217ba4651cec866
086259dc75d5b8ff5746f3ce4ebfca363ccac22452629bd16575dd842e6df7de
08f19641c292a2009bf57a9fd4e8ed2d81a4ef14ebbb63df6d43699912e24d0f
093876ca18caa27e7e93e2685a7e7ebd673f5a50c059bc33e7a1f8a006859d93
096b4e260977351651be43e97820a5b9531f9545b375b98e2250bdeff7fc87ce
0a282433a91f4089dde94f56e0ebd65d69007e2e1892215a9134be62b8bb8938
0a4263d356a6f841d367498edc93fe5fb7c3985b8e56716af09e9bec4882ff9c
0a88fa6fcdfae208f3c1976e86c38c9ac083da3db97382a4ce288d1c1ec1d2bc
0a925f79ca8b588c723b4ab0bc964eea263d30f9d850340556810b2a99909336
0adbdbb27f3458ac8660365a0b1826951fe6d8e338f88b576de230cb00bd5a78
0b71ead40bd738e6446f6ec7b83abe046ef8f465add24369fc1dbcf007ac5881

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.