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

reports under this root

#973,481

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

Confirmed in Bitcoin block #973,481.

Merkle root
15bddc275a00d72cc220e52707e8c351736b3c625e9de0b9cdc0bf24489eae26
Reports covered
1909
Sealed
2026-10-28T01:18:00.907Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #973,481

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

Verify it yourself

ots verify -d 15bddc275a00d72cc220e52707e8c351736b3c625e9de0b9cdc0bf24489eae26 crawlcheck-2026-10-27.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 1909 digests sealed under this root

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

00011d7bf5139de44d9cbef5919a2d1f3de3eb7c2bf4e1a29897440356d04577
002cb704477faf391967083ff5cf9a378419610897ab28a257d173a7fdf2c6aa
004ea723f805e03417cddd21b72aec30ac2cbba3387846cc059d4a42a8d741cd
00b494333486c8f599b2b3662c7b5824c8970ef4f28e13f15d334cf54014f99d
00b8401b0c73066dbbca714f774ce210224252df80609b02461c56e2b261928f
00bdd732f9dc2bcfed8eacbe442c931d138c9f16401bf4e8937caf922053fac4
00c12a1f5c271573ea14145be919fae3274633a2f5e6a8166cdcb64b316e1a2a
00cc0f0dbac40de3421f0df1b9da4d28c7cd5eb76799c2db8eb64f8befc88961
00d26ff8fd97c99c778c06d373fdd2e7507acb844e587aaa76f0e4cd6a85e8cc
00fb224c7775f89fc6eefc774bbf75b242c078e689fa0b8ded27624fcd90c14d
011811c1d86d7a87105ff2c037936578bb1ef1dca1c6fd09449ee6f33377f8e6
011b0f17da5b0c9e671ed345478e50d4723864232d443c3a94caa4b8585cc002
0161389903d2ace5a2cd6f81e368c486ce15e6635ce4be0d6b554cfaab1b64c3
01f8a469708e42b062780de71fe3f8c1f66c4775195723161e2ae7029d23a54a
01fccb196965175c6e83171418fc8a1097f80d6cb2eccf4253df86028e052330
0208148693b67973fcb39febf54a3ea0260f3f9e17cd2f49c413561302548195
021529152024d185c4c732684f91c01f706b32fd086a1e4f11895888b849bede
023cd42dd9bb7d86ac4da42f3e4289077c2aed7d7c3fbcb953c46d4978566666
02542260a706e8904cdc0ffd9e86cc1feb6576f77a4df0da3bebcf70033b3598
025863d850f83283852cb0f55a402c63c445606439e743b1cb9722c26cc90b6d

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.