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

reports under this root

#972,237

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

Confirmed in Bitcoin block #972,237.

Merkle root
08ff2d458091027426eec77da5dfd913e409413841db81a174f79a83dc5175e3
Reports covered
1483
Sealed
2026-10-20T01:17:39.307Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #972,237

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

Verify it yourself

ots verify -d 08ff2d458091027426eec77da5dfd913e409413841db81a174f79a83dc5175e3 crawlcheck-2026-10-19.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 1483 digests sealed under this root

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

0004c1a9cd56a830ee1a93567106505f5d960181c9405196cf9cb4d5657b96ad
000e5cf814080f810f45771810953b1bb0caf4485ed47c69cd86f298858dc8c4
00337120834fe73a1d9404ba0ae5e314443794eb3439db97c18f8fdf2089ffbc
004850d9ac900fee785ccbaa922d90d1746e232166c1a4e853974c009f854f2e
005d877102f183299a9bd4b238bd67904763d5eb7f601c616b7178ad7cdca0e4
00b44d9e6137366e699190d2ec84410e9742363da5ce9f45c177ef93bddd1431
00ba43ad1c2f5f236ec0b4239de426d471d2aa5032fe984348cc8d537096cdb3
00c9009c5689afd82f609fbe9e2c9f59f14a5d339c235d8ba3c373b45bcdcd96
00e7860030458d95a668e13e3a93de83a3ad2a4619bd7462a79b06d68d33007f
00ecd382302ede9e25f3619a028eff1da7c47acb94ea9335de4a190ffd5cd917
010e83c576e6c76c138d5ba4117f677b62da4bed4df42c9f52068e163a17db51
01f308eb7dd9a645143c9d792784c81e236fd9bf83596fd9ba0b9459516257b2
026391d09de7445e8dae277914de8b9ef7e60fc5f29ac6c8ca011f424b71d93a
02a33623e58c585baee187f7c0d00663cf21dc29e1bc27c9142c5f3628b0924d
02c75fcd1fb6bffc71c22a47388c65f93772f5c7f1cf0706ef1a0cece3223fe9
02e32bd07cbf5f71ff34bf611391aa6b47ea4db4820c00f0cecc050a6594972e
02ffd02192f179b099a21afa63c5b090041eea6b7951e476b43ce6726a1b97a9
0333c7dc85df0811235d2e9a3b2903ab2ee7fe0fcd1e1b005c3d19a776f72028
0346f7894b50445a97f926e9343564255d6f54291b0ee55376d7a846eedb09d7
03476e0dc23028a0cb6de101c6fc9aa75a476051c24bcfbf21dab8240f4cebac

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.