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

15,387

reports under this root

#974,327

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-11-02

Confirmed in Bitcoin block #974,327.

Merkle root
b54a8bea25ab373650743d8459bd4c8d39a4952a8664db0149c7b2510c24c149
Reports covered
15387
Sealed
2026-11-03T01:17:47.765Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #974,327

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

Verify it yourself

ots verify -d b54a8bea25ab373650743d8459bd4c8d39a4952a8664db0149c7b2510c24c149 crawlcheck-2026-11-02.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 15387 digests sealed under this root

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

000194516c41bc32648655dda02c1618ea4dc39b17843a24cbab53b8214ff57d
00042367b2207d8c41743417ca9c8db2198d82a4dd20abf91ec469099d3173ac
0004ef6831ffa51e7a7a48e1358c9a89991ed749cf1af82fff63b35c33c6d890
0005526e22357ce915a8e3181dd82079ce15b4ce0d8b0eed4f098927ae760aa2
0005a637eb28fadfac39ee1f0e92b73bf258e2647075b334747970a81eb88101
0006770b74bf710c9c262ea8f62f2e57363dafab8f0b69f8595f6731882d1fec
000edd6e82c32fe4d056fa7c556b9e63ef6e381c378e747ebce7a218b90c92a1
00155ec1984cfd0afb7100da68ad1c56731248164b589a499b606193075810b5
00209636523b4874b61e391591b934739394153f180d4f9ed00b323cbcad0fc0
00273ec7587045ccc203a61ec2cac2d7b8fffaba950bdf9653a6779a4d5e11ca
00340445d8320802f25e4686d6c0c043612ae56bb51fe5ce63afc41003b2f058
004967da9d8848f48ef26fd82fb1c0046138ad2b2e72c98e0d0889e0130f19d1
004da1478ebd83dcec9e81a1f667d6e3a9547b1062502f69224558aaa8d66292
004db7d4c37812d3df335c6e736d9c3a6919dc13e47911aa07e695fe3fb2b034
00564c9db4b66f4e873ccf3941ffc0d81d3a3b27a10b32368571d0016ab4a1bf
005eab04277fdd187fb95dda48bce8902c0cb2c50bd1e864988fd868138b647a
006177e3d232b7e6e0caba14f03e8b03d0ac9963175972c5cabfed9c35fd0e3a
0063cb415c7a2d459cc96e89545f8e9de8e97bb2882565a89a2fc88c4aa7437e
0067ecd3763a0d009894d221ee035999375f4e33d0f43aa27c20e03ee48163f9
00688efe9b5659ec3f251ac2c9585ab41b0621bc5fc04d5daef22f94e8f905d5

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.