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

reports under this root

#972,089

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

Confirmed in Bitcoin block #972,089.

Merkle root
b870bbb15cc3e4241bea47945f268dd3ba4d6a92e587120cddbff1a7a7ae2aa3
Reports covered
1922
Sealed
2026-10-19T01:17:42.382Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #972,089

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

Verify it yourself

ots verify -d b870bbb15cc3e4241bea47945f268dd3ba4d6a92e587120cddbff1a7a7ae2aa3 crawlcheck-2026-10-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

91 days anchored. Each links to its own root and proof file. Days are sealed once and never recomputed.

The 1922 digests sealed under this root

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

001996d793918cc95c455a32ad2868afea831a514867947fcbc5790009be959e
0032332cb2138c8ac792b383f09bb9db15b06c54f1bf3df6ba6d62956db6fd13
004ed1a62df72f8d329e676c6d8ef4cf2b7166724c7966e41e21c9df7d1e07d0
00659c406b8bc8604843b39731dd4cc89776d2ff4435d4389b6f68b59bc57e12
007ee8f0333768fdc07721ad1033e10665cb265bcb297ec2adc498ee2f39ed2e
008d496058a4c158dd4486ee65dca7618dc990eb789e4a4852489eb20c61bca4
009bdf42c7bb101899c1752d0525b36cc1ad3c05c7cc32cbfcdf2a666acce87c
00f839d4dd49b145d2dff09bdd93d1e050358192a11e4789714f98d717d54f6c
0105b1511bf85216ad338e4c7440ee6ac557eebb5c5fd6c21a2c089ec476e0a2
0130dda9555f6c5ee4d844bf5226b93fc587aea489d8f6ed1756e8b4a00b76e4
013a44f52886e3291e297b35e93f4fab54a19f4ad4c7b66800b72ab76f643dc9
015454db062a0c15ae8defc9973ffb5f01a2f949586004ff7125c3e9efc6c58d
01aff323afd0c9751f38612e0188966d5dece3e4aac35066db7c193d7c7ea02d
01ba0c1815d06a29ab81d52e9cd35536f887623445319f627fc4ec2b2331f7e1
01ba2c467862046096ae361f48300602318ba216b29238bc08c193eaa5a388cb
01bfbca2d512806fb97f68719f160480241dc71230271f0c362f19799987dad9
01fe4bebee7bc1c1c0d6141d78e44235eec10922ff40ca18415e497a4862a894
023d1a43ec5677e38ed69ccfe6486981c5dd404e6a3c53186cb2ffbea6740caf
02e32713fa45d1081b66cd4c83a0fb0b37b4e1677033696fb2c951f44a8c5bdb
02ecfe6209080bde69be5e2c39732b76a38806612e03bf39a2818c0ddb9f5bac

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.