Verify a receipt, live in your browser

The runtime (Pyodide + the cryptography wheel + the rfc8785 wheel + the proofbundle wheel) is served from this site, not a CDN, and downloads once (~14 MB) on the first verification, then is cached by your browser. The verification itself makes no network call.

It is the same code as pip install proofbundle==6.0.0 && proofbundle verify. To rely on nothing this server tells you, run that CLI yourself: it fetches from PyPI directly and pip checks the hash independently of this site.

Checking the checker: this page pins the SHA-256 of the proofbundle wheel it runs and refuses to load one that does not match. You can cross-check that same hash against PyPI, on a different machine if you like, so the pin is not just our own claim:
pip download proofbundle==6.0.0 --no-deps
sha256sum proofbundle-6.0.0-py3-none-any.whl
expected 3c206fcff592833a75d712ed421e4b9f6aaf7d1fa857b2fc0ba50839d3dfe14d. Package licenses and asset provenance are in NOTICE.md.

What this proves: the receipt's payload is signed by the stated Ed25519 key and is Merkle-consistent under its stated root, checked by the identical library the proofbundle 6.0.0 CLI uses. This in-browser build is pinned to 6.0.0 (hash above) and was built on 2026-09-12. PyPI may serve a newer proofbundle; pip index versions proofbundle lists the versions it serves, as does the release history on PyPI. Pinning is what makes the hash cross-check above something you can recompute. It does not prove the result is true, the eval well designed, or who the signer is unless you pin a trust policy (see the deep dive). Verifying a tampered receipt here fails, exactly as on the CLI.

A PASS means: the signature is valid under the stated trust policy, and the explicitly checked artefacts match the signed digests. Truth, code quality and provenance from a particular AI model are not confirmed by it.