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

reports under this root

#973,158

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

Confirmed in Bitcoin block #973,158.

Merkle root
e46f73559d4f577ffb66962c1f6880901d6285922d43848f397ff2895b34075f
Reports covered
1691
Sealed
2026-10-26T01:17:12.900Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #973,158

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

Verify it yourself

ots verify -d e46f73559d4f577ffb66962c1f6880901d6285922d43848f397ff2895b34075f crawlcheck-2026-10-25.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 1691 digests sealed under this root

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

0040ff99a86de5e59e193d7117a16d20a1b014e438a479009ab589f4a4730a0c
005947f3cfe34185734f8841cb5d1a3f69c3f5f5889090b886f997123669e89b
00e4281a3715a4b7b9550cba3e14e872653b2f5916be1389c83ddd71c7faa61a
00efd5c33ceaf768f79ea723f57a28c075b510a867c3fb744c4b306830430efb
00f9694e076f84487b8dd89f894e8f086b8cc0487cb2b464e518d05a94c9f15d
011b7140276f7553097775cd95bbf4ae0eef0c69ef578585e1a8e6be1cbfb4a7
01716f708aff8b7464b6b8e362c386a2d542fcbfedd74b0c967fdc5e8df7d350
01893d7269f41111ac92fee70a8e0f4c02abda5599314e1a2966bcb695262160
01dc26af80cb658efc38316df90fe47f804c89001b34d3f7ba9aff242203ae7b
02399cd7ebf44c73398c47f396d3b1b0845aec5403c86ee5e2f285609664ef7a
023b2586608fc9b43c7ba9c0737567e4f5217b3c318718c14120aaeecdacf5af
02451d47cf5a9bed59a01e0e5d8dabde7075350970a0594c033f628c51bd1fe4
02567a3371c6f261299ca0db85ed891e69f3bd47183eae592106005847034431
029d13e68c293b973ed0f270fc373d09cf36eba69bce83834b15466bb0bebbcd
02a07129aa509d0a22bbfdd48634ac1ce70858a0a34396b1aba074af288d789b
02abed34be1f121b8ac866bb733308b38c6335fbf43913ed1b95eacad320a82e
02ac5c73b8df8db0d941c6e31b20ca89db90200b7f670feb286cf1d45dbb629d
02b055a64f7e024cf4e7dd33cd2c1813cbcd5c6b911e3ed9275ba9595a084a6c
02c53a1c71e297e4a3c7230cc48a4a773dda8a4c97bfcff9c1f247414a204ffb
02caa4ee5102d583577ad9b757d3cd90e9a1b18aed28e0b337b7cfb090f3aeec

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.