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 running 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.

64

sealed days

80

reports under this root

#969,082

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 running on GitHub, outside our servers, re-checks and co-signs 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-28

Confirmed in Bitcoin block #969,082.

Merkle root
a857f8cbf5a1f7691e0c45c9c82336a8c06fea5668ab2bf104c195668b85e9ff
Reports covered
80
Sealed
2026-09-29T01:17:40.019Z
Calendars
https://a.pool.opentimestamps.org
https://b.pool.opentimestamps.org
Bitcoin
block #969,082

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

Verify it yourself

ots verify -d a857f8cbf5a1f7691e0c45c9c82336a8c06fea5668ab2bf104c195668b85e9ff crawlcheck-2026-09-28.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

64 days anchored. Each links to its own root and proof file. Days are sealed once and never recomputed.

The 80 digests sealed under this root
0127db42429e8d0331d7823332fba3d2029517a06a0dea0bfe183ace2db62257
03d1ec56a0a012b612ef8669085b3c35bb6139962189fd1cbad7ce9c8ea8167f
03e44988beeb4d60afbc1607501b0e2f00fb5ba2b2c24d3468a85a5601c78f52
04ca4b145b26777135a5fda9b109682b367b72b4c7a24785e765c4763fc775bb
0cf80b618a6feabf7fd3bfe515ccaa553b28c51c9fc84467f6cd8556778962bc
0fbf6198f1ec5e9a07816442538633b825efc7047e4831a6f36ae3389a5cd2d4
11797f94bcf97b499e34689ab0ad522aaed1f22374103dc0d281645ec9714eaf
14629cd3bc7284d77a416601dcc1efcebd39034cb3cdaf0881e2651e5cebe172
148ea8e26a8c4a4146412048d9f5b32941e1f513815f540d5676ac6500ad6c22
1811228473a2c9915b2d515bd5c88414fc3b847875fe35b50dbdfbb8000407a0
1fa846bb9271ba8de06c9c44e507a20037a097e7e030a176e9c4777050b7c9d0
2071f10246c582c266f5ffb0120590f10442f7136c8622d1d32642cb5b4c62d4
2263b349ae06bfdacd4f8f5a673f003dae0daee6e6de0de9945da6f780fb2ddf
244336535f62b07bbfbf3511d642737d40c43cb8947fd5f864184b557cd491ea
25efd4300e56df34d518d972d380d1d03f8fa3fd8d37d1909c9714a05ca6ef68
2a3035f428ea845764b0a2891ca2d1a48b89e9c2e9d3396ad586783927f2cddf
2b71e0b55d22254cc3cacd0e80d5d20c69a56a1692bd8a6ae922552b2469711b
4e33f425064a51b8b136bc89118c7fcd2a6d95640ccd52b24a9b5396e9d8da85
523a4e70fa8d18c3dae003bcc787605a6b5b33bd5503937d851a98d68bcd9eb4
568d3334f93bb9afecf959875043a49ba3a632d2c28bc3d24a4b4edd03beb786
58d1ef60ce667e6d75877063cc12f405297661c314034b2e8bac926837364ccc
5a3ba5a95d759e08b3edf564f103958ab015cabcb4304060202b38498dbf4e99
5cf299f45a71e748d8be9d455ea1402725a03c412d0f82574f74be97c919ab63
5f25338fa52a2dbda339ef85bd781da5f0919ad86259fb69e24c72d55c8098aa
6b51e04f132c44800d84bf9be5de1bafd87f7e8d5972d97c25b2c70204f2bcfe
6c903b5b8e6bcfe1153343b318a96d55c61a209652d169fb202097dbf2e4ece3
6cc1d7214eec207efde0b51685f5ca721d6a6d2ba1b0c64311a029c8d750ae0c
70a9e7e56dabd20a3dd517017e4d3153714abbd7116c4204b13cad867694574c
781e731e76cd9b21c20fbb0f900c6ae655ae9632f06bc6a74e3f2cd1322296cb
7a4d06a13291268358a152ce57ff0c4b1d4e095ffb650438c2630528a3f79e38
7d0c4ee4301c3fc8677687df06aaaa7c69369d9f38900712a1a686bbf4cdd790
7d1a74e3274cdf57fcade3fe24a484125c9d07f05003dac62b7bea72210f47b3
826af13be296ec155777255b8d5f134c2e34435146c1b17fc0257cb9155c162f
82bea61ac386f4c8dee2753c8107b88f988d855ef6240a2406096bff9c1f2d16
83932a8f5d6ae8f7d500787e4cc4ea57f75a0f4269ea7c218d2ddafd4afa0438
8419bb2d2e5554064cd0ea3a9c075ca387f0a86a80a3588b98bbbf7257ccbb4a
875a16eeaaeaf3b4b4db9f53faff557dd967cc4b3eb460b64f8fd83db2c4fc4b
8af9242e43a5cf9969e865fd5c98440869e23e62bc52407abd82dd5d419999d0
9348e4e5d4bc1f0617eab18be176b388e6f464e65db3e79dd469d26a65017826
960577f901ac58aeefce3d2cef8cf4341506a9d4d13eb75212c4ee27c3753a2b
98f854be3d0591cd7b0fff073efc605230a1530325ad1f1bad9d8507fe28a113
999d91ae50e5d81c1f7cda98bd130d4627f8ec6bf85660637596ac87c3bfc579
a38596bc0f250a93916a66fba4bdda2843514fc0272f76b5a930c22fc8de2369
a576b1d8c1e1cb5dd41f99c7b2272e5908926f8ec5b0663fac15bc279d26f620
a7c9e34d027a3bf8672c78698d2b65f790f4f452bfce00d509e4101979b428a4
a8f2dd94a2cb0f8d48ea3ba9bf724d589c7235ce9cff2e3a26bce691a8004e22
aa497912cfd3ed86df9ce82506bd2c37c36d4a4034aeeb31a90e7d03f974052b
aad25ca38307cfa83df4ebb1a5fb201262f43d49a2abd2f6f1ac80e1bc017238
ab0e7f8f2bc94f6b55091aa25a9e02dfc1f056fae044ddf1b682fe77be1d1472
ab1154bd227ff978e4a4f83b8c5e8db55ac6284490a76e8ff09361ce477e9e5a
b0081f4b00c509726b479c64850e3e9e7c200f42663d2211d84045bbcd19a8ab
b565a97661bfd8cd71a37951cfde94c564a7286c378fa545b3521dd74c2de81c
b6055a5067b251a3c644564e838f6c9c27c103f075a4ea880799601bf43c027d
b6c5c72a45cb31b895d253db5d30f7dce942befc90aed9932052ba8d0fcc6ebc
bfe596c7b0b32b22ba1784dc765473d020358d83bed43b4da9f7404e2b5d90b4
bfe96cd62726911684ae165a2afcfe64ff14489f53a9dd97314d6312974c5597
c180bf2fc89ebaf87f623dcd94c453e3619408f11593c16a0f4047d0c4e72065
c4a7f800ff3d6df87e1eb2b6e3da54992c89c787b37d89109dfa8d28b5f5108e
c6505def8edc92c3490667a61b48743969082f6331f1bf8e1f11811b6b7303f9
c991b035122501c153c20ef730190f8bcc9b1fc4d64adb874f92b462b6d14f1e
caa08b209d9c3ae109f24ba95d6f51ea5d58aa0ffc2a8965a7703bb05185e203
cb81304f12dfe09078b7cf336602048065d818c558cab58b2f68870658742824
ce2f36bc0d301a675d06b3d1b91b4f65fdc8c5b6aa58fef489060b694b8694fb
d0421dd12be4c26461e524ece23284260048da224b4f85d1b631022826e9760e
d0c4ae06c3ae9c236ec2d3d956dd715b689d65858f7787dc34012efd9c4134f9
d4ce019a254947a7a43c4047ace117f7f5c210a50e97021ffd97175efb95a8aa
dcdc13b03bac1c642ac67fe4dd1d4f3b452ef51e2f94687237150ce5e4cafcd4
dddaf0cefea2a0f9f04e73e192be47a84111a93c5785f5b2bc1a14c8e057961e
e2c7a02da1620f024f2872fe3b3beae5b0eab0e24d7aee4c25725c01e335843e
e51dc13810ef2cd72fd54fb38540045091cdc7e495a33de2ca60422eedf7d333
e95c8eae0d1024fa61dead7af39b967f4a5508607730c01a8aa2c6c34ebba7dc
ef14bb3fb5438e5b505239cd9501d630c233e5ba6f7bfbfdee70b6f421e2b73c
f012fceecdb9aea60e1c6a69f65c145057a8124f87878299993a351926394473
f6409f8cdf09ee5f3b6c18cf6003d4484d3d1f8c1bb29e53e7ba8bd2f3c1fe16
f66df7176d981ec0ca12ee3c0cda6beea4f92beace7fc08dfd48a1eb5ff35eb5
f73e55ed47022d2b9eb710a40242adab1f04e9c67c1c390bf065356678e09c01
f80ccc195f0785b19b0d4bfd285104795d8a27a7c49953f99d2d3befb6711ec6
fbaa6977db720d4cc0482d27cbf397fb885475da4c4f821d2d4edf2a65ec97cf
fd9a60abe75d206be6228c9f15524b0a53c049f406676c12f6741b797646ba00
ffa66ce0ad76fc1c764133f83d66dea7aa45ae2a830c913f7a462e3caa27062a

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.