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

169

reports under this root

#967,357

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

Confirmed in Bitcoin block #967,357.

Merkle root
c43b061d34dc378796f14369fe520821cabb99bff08d640f821e1bd241011720
Reports covered
169
Sealed
2026-09-17T01:17:45.773Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #967,357

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

Verify it yourself

ots verify -d c43b061d34dc378796f14369fe520821cabb99bff08d640f821e1bd241011720 crawlcheck-2026-09-16.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 169 digests sealed under this root

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

0285217a9067dade5af5aad0deee7d867f578a20b83005578c0a7975dc4fd0f8
041d1ea8a9ed9904ea6e8cd6ff025511be951feb6e31cdcc0359568d3ccf2351
071250573610598d82041b3371109ef39a5a5e61332c6d2d88794977b84e9259
089984999f8405b2f54603040d422002fa6e61fad5b7e91bd131b2e37381c3fc
08a6b2f68bad6ff4a7286281bf67840fb1e15494cc3df4c54c12190871bd6df7
095b78bce129e3b2b0e487ffc39d53492e5c67411f3e4363b2320b0a0ce9472c
0a9b29dd13db355a2af61fc4948de7df0ecd190a7864a3fc05e28391faa54d0d
0ace277fb4885ec36b444e8a85a58f8afcfac4dfa6ac399bbff54f88937e65fa
0bfea5aa22b27fe73ed6e728ad114a2568d2d5c4060c877edb2e49b875d5feef
0e84e2bfa6c1d094a62e7df48eefda01d51adfe279651d31511187d9b41fad6d
1139fa27c741da479f525abde28d8729e7fb402d89d0dc7526bc840e16ba05ad
12cbfadb796fa84b8c7a55d001d1b5162168f0446fe1dfbc2ef36cd7d6f8b65f
1363bfa93c6b0106b6293482447a5a4159487f27469a12ab142f016c6700f40b
14076eece30d1f926a0c86d4c223e9426f0fb746559280a79cc2c2ebc8645d14
14c82f11396f1b5ebb08d11fcd7f1232dde927c18a80ff9c9a33e3ef961c09ea
17a3fbe67e7e7b2bc5aeb17764f4e62beee7201ac2fc82f643c68e9981804c57
19d7dc63b02ae41e6ad956562a72f71337594e8526b1831496b4f9a735662de8
1b5b604a028425fc9f6210dac5cfb2822559dce52296efc79bdc5b238f2b3c60
1c46131cc070e3247928db254e9314ecb3244976d3e5b16a75f5519821284a94
1d807542de3138cbdfd30049c00858e30c5162da223979c830d8ee7217bc90dd

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.