Second update, and the external side is now the main story.

Since the last note, proofbundle moved from the v2.1.0 era to a hardened 3.6.2. Two release lines did the work: 3.6.0 became the audit-candidate, consolidated behind an independent Rust second verifier and a fuzz-clean surface (1848 tests), then two security patches followed. I want to be plain about why they existed: our own adversarial passes found two false-accept verdict bugs in 3.6.0, a subject-pinning fail-open that could reach VERIFIED and a canonicalization path that could accept a non-canonical but validly signed statement. 3.6.1 closed both, 3.6.2 followed mutation-gated with the release chain digest-verified end to end (2017 tests). All of it is in the changelog.

The Colin interop I flagged last time has landed. The decision-receipt vector that still needed regeneration now conforms to the strict v0.1 schema, its OpenTimestamps proof is Bitcoin-confirmed at block 958761, and it has graduated into the conformance corpus as the cross-implementation case. Three independently built verifiers, proofbundle's Python and Rust plus Colin's, now agree byte-for-byte on the same cases, including the deliberately broken ones. He also contributed a set of transparency-log anchor vectors, cross-run against our fixtures with his Go and Python verifiers and ours, with no divergence.

The part that matters most for an audit grant is the second reviewer. An independent reviewer (No Silent Landing) reviewed the shared conformance candidate from the bytes upward and found a real seam: our report claimed a six-of-six conformance result that does not actually reproduce from the committed measuring instrument, which produces five of six, even though the underlying security behaviour was correct. I reproduced the finding from our own source, conceded it publicly, and a successor iteration is fixing the measurement layer so the delivered result provably derives from the committed code, before anything is adopted. The security fix held; the measure itself asked for another pass. That is not a setback. It is the exact function of independent review, and it happened in the open.

Upstream, the eval-result attestation predicate this work is built on is now in active discussion with the in-toto maintainers, with a real worked example verified in the thread.

The grant stays scoped to the same thing: an independent security review and remediation of the trusted core, verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI and build provenance, and threat-model alignment. What has changed is that the trusted core is firmer, and independent eyes are already on it and already finding things. That is the case for funding it properly.

Project update:

When I submitted this grant request, proofbundle was already a small offline verifier for AI evaluation receipts. Since then, it has reached v2.1.0 with decision receipts, universal content roots, and the anchors[] verification layer. That release was verified with 683 passing tests, clean lint, and a reproducible build.

The more important change is external: an independent developer, Colin from MarkovianProtocol, started building decision-receipt and OpenTimestamps interop vectors against proofbundle’s canonical path. I did not want to claim this as progress until there was something concrete to check.

That work is now being moved into the conformance path. One vector carries an upgraded OpenTimestamps proof confirmed at Bitcoin block 957504 and can be checked offline. Another reproduces proofbundle’s canonical bytes byte-for-byte, but still needs regeneration before it satisfies the strict v0.1 predicate schema.

I see that mixed result as useful, not as a problem. It shows exactly why the audit matters: proofbundle must clearly separate what verifies, what does not yet verify, and where the trusted core must fail closed.

This strengthens the case for the grant. The project is past the toy stage, but still early enough that an independent security review can shape the trusted core before wider adoption.

The grant remains scoped to the same thing: an independent review and remediation of the trusted core — verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI/build provenance, and threat-model alignment.