Theorem OSS Verify: Free Crash-Freedom Proofs for Open Source Projects

Theorem Labs has opened its formal verification pipeline to the open-source world. OSS Verify is, in Theorem's words on its OSS Verify page, a free program for qualifying open-source projects that uses AI to prove properties about compiled binaries. The headline property: no input makes a fuzz target crash.

The timing follows our coverage of Anthropic's result proving 123 libraries crash-free, where Theorem supplied the formal models that let proofs run at the assembly level. OSS Verify turns that one-off project into an enrollment process.

TL;DR: questions maintainers ask first

What a crash-freedom proof actually means

A fuzzer feeds a program millions of inputs and watches for crashes. It finds bugs but can never show their absence. A formal proof states that for every possible input up to a size limit, the program behaves in a specified way. Theorem's example theorem is that an entry point never crashes on any input of up to 64 MiB.

Two details matter. First, the proof is about the compiled fuzz test binary, not the source code. That avoids trusting the compiler, but it also means the guarantee covers only what the fuzz target exercises. Second, proofs are written in Rocq and checked by its kernel, so you trust the small Rocq kernel instead of Theorem's tooling. The AI can be wrong while writing the proof; the checker catches that. What the checker cannot catch is a theorem that says too little.

Testing, fuzzing and proof compared

The third row has a sharp edge. "Does not crash" is a safety property: no out-of-bounds read, no use-after-free that AddressSanitizer would flag, no hang. It is not a correctness property. A parser can reject every input gracefully and still return the wrong tree. Theorem's own page frames the result as typically implying properties like memory safety, which is valuable for C and C++ code, but it does not certify business logic. A specification gap remains a gap, as coverage of Anthropic's earlier project also noted.

How this differs from OSS-Fuzz

Theorem borrows the OSS-Fuzz enrollment model deliberately: a folder per project, a Dockerfile, a build script and a project file. If you are already enrolled in OSS-Fuzz, you can start from those files. The difference is the output. OSS-Fuzz gives you a stream of crash reports when something breaks. OSS Verify promises a proof when nothing can, and a private bug report when the proof attempt uncovers something. The two are complementary: a good fuzz harness is the precondition for a meaningful proof, because the theorem is stated over the harness.

That dependency has a consequence for maintainers. If your harness only calls the decoder on well-formed headers, the proof covers only that. Invest in the harness first, with realistic entry points and the sanitizers you actually run in CI, before spending anyone's proof time.

What the 123-library project told us

In the earlier Anthropic work, as we summarized it, Claude wrote Rocq proofs for 239 entry points across 123 open-source libraries and the effort surfaced hundreds of bugs along the way, with explicit scope caveats. The significant point for OSS Verify is the process finding: the proofs were produced by a model working against a checker, with Theorem's RISC-V instruction and Linux process models supplying the ground truth. OSS Verify is the productization of that loop, offered at no charge, with the enrollment gate acting as the queue.

Two open questions follow. First, throughput: Theorem says proofs can take multiple days, and it prioritizes widely used critical infrastructure, so smaller projects may wait. Second, trust in the chain: you now rely on the Rocq kernel, on the formal model of the RISC-V instruction set and of Linux process behaviour, and on the claim that the proved binary is the one you ship. The reproducible-build check, with targets built twice and hashes pinned, is Theorem's answer to the last point.

What to do if a finding arrives

Because findings are private and AI-generated, treat the first report like any unsolicited security email:

1. Reproduce the crash from the supplied input before doing anything else.
2. Review any patch line by line; Theorem says it may not have been reviewed by a person.
3. Add the input to your regression corpus and fuzz seeds.
4. Decide your own disclosure timeline, since the program sets none.
5. If the bug sits in a dependency, expect it to go to that project's maintainers, not you.

For teams building agents that write and fix code, a proof checker is the kind of external judge that keeps model output honest. If your agents can modify repositories or run builds, AgentBeam, the agent security platform from the explainx.ai team, covers the complementary risk of an agent taking a dangerous action.

How eligibility works

Theorem says projects are reviewed individually, with criteria similar to OSS-Fuzz: maturity, active maintenance, real-world usage, an OSI-approved license, and whether the code handles security-sensitive work such as parsers, cryptography or decoders. The repository adds a public git repository, at least one fuzz target, a buildable setup and a security contact. Only core maintainers can enroll, and the contact email must belong to a maintainer.

Widely used critical infrastructure gets priority, and projects with under 1 MB of binary .text may be verified sooner. The requirement for static riscv64 builds is the biggest practical hurdle: many projects will need to port their build.

How to enroll

The theorem-labs/oss-verify repository is Apache-2.0 licensed. The flow, from the README:

1. Fork the repository.
2. Add projects/<your-project>/ from the templates, containing project.yaml, Dockerfile and build.sh. If you use OSS-Fuzz, start from those files.
3. Fill in project.yaml (the README names primary_contact, publish and disabled, and points to docs/project-yaml.md for the full schema). A patch_style.md is optional.
4. Run tools/validate.py projects/<name>, then the reproducible-build check tools/check --twice <name>.
5. Open a pull request and complete its checklist.

After merge, Theorem builds the targets twice, pins binary hashes, proves theorems and privately sends findings. To pause, set disabled: true; to leave, delete your directory. The README also carries a warning worth repeating: the build tool runs the project's Dockerfile with network access, so use it only on trusted projects.

What is claimed versus what is shown

At the time of writing the repository shows one star, no forks, 105 commits on main, no releases, and no published results. The README says some projects are seeded but does not name them. The strongest public evidence for the approach is not Theorem's page but Anthropic's separate research, which we summarized in the earlier post and which reported hundreds of bugs found along the way. Treat OSS Verify itself as an announced program, not a track record.

The caveats Theorem states are candid:

• Findings and patches are AI-generated and may not be reviewed by a person before sending.
• There is no disclosure deadline, which protects maintainers but gives them little external pressure.
• Bugs in dependencies go to the dependency's maintainers.
• Proofs cover the fuzz target, so coverage depends on how thorough your fuzz harness is.

Why this matters for builders

Formal verification used to be reserved for kernels and cryptography because proofs took expert-years. Models that write Rocq or Lean proofs change the cost, and Boris Cherny's remarks on Lean and TLA+ with Opus 5.5 point the same way. Theorem's bet is that a checker you trust plus a model you do not is a good combination. For maintainers, the offer is unusually cheap: if your parser already has a fuzz harness, the marginal work is a build script.

For consumers of open-source code, the practical effect is slower and subtler. A verified library is a stronger dependency, and Anthropic noted that proofs can be reused across projects that share code. For teams worried about AI-written code in production, see how verification fits next to Claude's 3SUM claim and what Lean showed and our Fermat's Last Theorem Lean proof coverage.

Should your project enroll?

A reasonable decision rule:

• Yes, consider it if you maintain a parser, decoder or crypto library with an existing fuzz harness and a security contact, and you can build static riscv64 binaries.
• Wait if your fuzz coverage is thin: a proof about a weak harness is a weak guarantee.
• Be cautious if your Dockerfile pulls from untrusted networks, given the network-access warning.
• Plan for review, because AI-generated patches need a human before they land.

Related reading

• Anthropic: Claude proved 123 libraries crash-free
• Boris Cherny on Lean and TLA+ with Opus 5.5
• Lean 4 formal proof cost collapse
• Claude and the Fermat's Last Theorem Lean proof
• Claude 3SUM claim and what Lean verified
• LeanGraphSearch for Lean 4 provers

Program terms, eligibility and repository status are as of October 23, 2026 and may change.