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

113

reports under this root

#967,491

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

Confirmed in Bitcoin block #967,491.

Merkle root
c60446f07a7546283da00e2f46fc6df7d4b73190b4e362001cbac2258cd86606
Reports covered
113
Sealed
2026-09-18T01:17:06.502Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #967,491

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

Verify it yourself

ots verify -d c60446f07a7546283da00e2f46fc6df7d4b73190b4e362001cbac2258cd86606 crawlcheck-2026-09-17.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 113 digests sealed under this root

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

031622487cbb5cc30f384d3be29cfbe39b2ce7ba48b7bdd1d6c9cb2e83cd25a9
04d8cbd2ea7f7d17cc7885746724e747963bc3ecda6960fd009e36b2c9d814ea
07a1388595c0d093ec0235f1c2ad3e1696fb7c7eec3b2129ec7bc87dde21689b
08928eba6d91c5bcc5255cb96efac51d2ecd34c2ff1ea72b9aee163127d56690
0cd9f63fbd905300d54fc3ab37830f70fb6cfff9ac6e653a778cdd7ceb5e9cfb
0ec1eede9cd2d2168db995a480080dea63ed279a2091e80a61f6eeb5ae024bfa
107a97b416e7d2d07ad5e85e9d6e12ba1cb4211eedd956760601432ee29ac1ab
165ea275e18337d56226e465b957ac0b5395df8e74aed4a9de5f58e9d0723669
16b8e009d9606c308e32a65c3ebebad2eb7fd1dac9602d2137d0bd9219e0c96b
1ca13bb89bc55626b73f17eea835c1c7ee40a94ce8e1e5e1213b9598a64c5c4a
1cd65dca23df81966fe170370f480c8f9775e71712e845a064a5590e7c775211
1faef13848046ec7c6b87e8a9ac864f6a063dedd46e3e2e0b3ee1f0765597fe4
20266ce8c4369eded46285bc761b8c38f9bbf47573c3cb03e2107aa5e3018f50
243e52f7b83113d7f88a98393b6c899a3d18c7f6311da9f5a54f5a889ea3452d
25d6f1cc8040841ec5b03aceecd27c1f41311d9135446e844b41a68048416fed
25e62cbef4fc1f617a286940075389b58dd23380187722bb588bc1fb65501b8f
260f42a82ff1be9dd6d9dadef8d5c54cb3f1ff48e635f2d64823de67ac0241ef
28f4e520562a9f484a741696cb638b9912e8944395e09b8ec79f8c1b67720741
2a69d3b36084eb7b1af3ba032ea53a6df07a3483d8c077271838212b8b6dbfc1
321c138fca5825505b5235c1a5e5c6299ebdd07454d9521aae1451c2635fa031

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.