Project summary

AI safety evaluations increasingly produce numbers that later influence reports, deployment decisions and governance discussions. Today those numbers are often just claims. proofbundle turns an AI evaluation result into a portable, signed, offline-verifiable evidence receipt: anyone can later check who claimed what, whether the artifact changed, and which samples or commitments the claim covers.

It does not prove that the evaluation was correct. That boundary is intentional. proofbundle provides authorship, integrity and auditability for the evidence layer underneath AI safety claims.

This grant funds an independent security review of the trusted core so third-party evaluators, researchers and governance teams can rely on the receipt format without trusting me or a server.

What are this project's goals? How will you achieve them?

Goal: publish an independent security audit of proofbundle's trusted core and turn the findings into remediated, regression-tested open-source infrastructure.

Milestones:

1. Freeze the audit scope

verification logic, bundle parsing, canonicalization, SD-JWT selective disclosure checks, anchor verification, CI and release provenance.

2. Run the independent review

commissioned directly from an independent security reviewer with applied-cryptography experience, selected transparently. OSTIF could not take the project on at this stage (they focus on widely-used infrastructure), so their published audit-preparation best practices, written with LeastAuthority, are the baseline this project already follows.

3. Remediate every confirmed finding

each fix gets a regression test, mutation or fuzz coverage where appropriate, and a public changelog entry.

4. Publish the result

audit report, fixed release, updated threat model, and a 30-minute reviewer path for funders, auditors and AI safety researchers.

Success means a third party can inspect the code, reproduce the verification path, and decide whether proofbundle is safe enough to use as an evidence layer for AI safety evaluation claims.

How will this funding be used?

Entirely toward the audit.

At the $5,000 minimum:

- scoping the review and selecting the auditor, following OSTIF's published audit-preparation best practices

- first focused review pass of the trusted core

- initial remediation of confirmed findings

- public progress update and scoped audit plan

At the $12,000 goal:

- broader review coverage across parsing, canonicalization, SD-JWT checks, anchors, CI and build provenance

- complete remediation pass with regression tests

- public audit report

- hardened release and updated reviewer documentation

The grant is for the audit and maintainer remediation work only. No marketing, no unrelated development, no private product work.

Who is on your team? What's your track record on similar projects?

Since submitting this proposal, proofbundle reached v2.1.0 with decision receipts, universal content roots, and the anchors[] verification layer. The release PR documents 683 passing tests, clean lint, a reproducible build, and version consistency checks; the suite has since grown past 780 tests.

The part I am most confident about is that the project is built to be checked rather than believed. There is a public threat model, a formal spec, a security policy, a reviewer path, maintainer governance with CODEOWNERS, mutation-gated tests, and offline verification against external RFC 6962 vectors and real Sigstore Rekor artifacts. There are no custom cryptographic primitives.

The newest signal is external: an independent developer reproduced proofbundle's RFC 8785 canonicalization and content-root binding byte-for-byte, and two of his worked vectors now live in the public conformance corpus, digest-pinned and credited, one of them with an OpenTimestamps proof confirmed at Bitcoin block 957504 that verifies fully offline. When one of my own claims about his fixture turned out to be wrong, I corrected it publicly in the same thread. That is the working culture this grant would fund an audit of.

What are the most likely causes and outcomes if this project fails?

The project can fail commercially and still produce useful public goods: a published security review, hardened open-source verifier code, reusable conformance vectors, and a clearer threat model for AI evaluation receipts.

The main conceptual risk is not that proofbundle proves too little. It is deliberately narrow. The risk is that users overread a valid receipt as proof that an evaluation was correct. This is why the threat model, CLI output and docs separate CRYPTO OK from policy, assurance level and limitations, and why the project maintains explicit non-claims.

Two practical risks are worth naming. First, this is currently a single-maintainer project; the mitigations are a small trusted core, public governance (CODEOWNERS, maintainer and trademark policy), and the fact that everything needed to review, reproduce or continue the work is public. Second, since OSTIF could not take the project on at this stage, sourcing the right reviewer at this budget is my responsibility; the scope is deliberately small to keep a focused review affordable. And if the audit surfaces serious findings, that is the grant working as intended: every confirmed finding gets a public fix and a regression test.

How much money have you raised in the last 12 months, and from where?

$0 raised externally so far. The project has been entirely self-funded out of pocket, covering running costs (rented GPU compute, GitHub, AI tooling, and my own hardware for local development) plus all maintainer time. This is the first external funding request. In parallel, an NLnet application is prepared for the next CodeSupply call and a Foresight Secure AI Grant application is in preparation. OSTIF was contacted about facilitating the audit but could not take it on at this stage (they focus on widely-used infrastructure); their published audit-preparation best practices remain the baseline, and the reviewer will be commissioned directly.