# Claude helped prove crash properties for selected open-source binaries

> Anthropic reports machine-checked proofs for 239 fuzzing entry points across 123 libraries. The publicly released subset and its model show exactly why this is narrower than a bug-free library guarantee.

By BIGCHANGE.AI Editorial

Published: 2026-10-23T17:26:39.759Z
Updated: 2026-10-23T17:26:39.759Z
Canonical: https://bigchange.ai/blog/claude-rocq-selected-binary-proofs

![Conceptual charcoal illustration of an unbranded desktop monitor displaying unreadable code-like rows, with a small orange section highlighted above a keyboard on a workbench.](https://bigchange.ai/api/media/file/claude-rocq-bounded-binary-proof-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. No actual Rocq session, verified binary, theorem or proof outcome is depicted.

Anthropic and formal verification company Theorem reported on October 22 that Claude helped produce machine-checked proofs for 239 fuzzing entry points across 123 open-source libraries. The result addresses a stubborn limit of testing: a fuzzer can try many inputs, but cannot establish what happens for every input within a defined range. The claim has a precise boundary. It concerns selected compiled programs and the errors their test harnesses detect, under a model of the machine and operating system.

## The big change

- **What changed:** Claude generated proofs about selected executable fuzz targets that a separate Rocq checker accepted. For the specified inputs and modeled environment, these proofs cover paths that repeated test runs might never reach.
- **Why it matters:** Library maintainers can use such proofs to rule out particular crash and sanitizer failures in the code reached by a tested entry point. A developer still has to judge whether the test's assertions and the machine model capture the failures that matter in deployment.
- **What to watch:** Theorem has released a smaller, inspectable set of proofs and the Linux process model behind them. Its published scope and trust notes give reviewers concrete places to examine the connection between a checked theorem and a real binary.

## From a fuzz test to a checked theorem

The work starts with fuzz targets from Google's OSS-Fuzz program. Each target is a developer-written entry point that feeds generated input into a library and fails when it encounters a crash, a sanitizer report or an assertion failure. Anthropic and Theorem compiled targets into static RISC-V Linux binaries and expressed their desired behavior as formal statements. Claude produced proof text; Rocq checked whether that text established the stated theorem. The checker verifies a proof against a specification. It cannot decide whether the specification describes every behavior of a deployed system.

The [Anthropic research account](https://www.anthropic.com/research/formal-verification) reports proofs for 239 entry points in 123 libraries over a few weeks, after Claude patched bugs it encountered. Its [technical appendix](https://www-cdn.anthropic.com/files/4zrzovbb/website/6867eadf760258fa8b42a504600cd3c036d16358.pdf) describes the claim for inputs below 64 MiB, across modeled memory layouts. Where a harness asserts a functional property, a proof that the assertion cannot fire can establish that property within the same scope. The appendix gives an LZO compression and decompression round-trip assertion as one example. A proof of that assertion says more than the absence of an invalid memory access, but only for the behavior the harness actually checks.

## What readers can inspect

The [public proof repository](https://github.com/theorem-labs/oss-verify-proofs) is a subset of the reported work: at our October 23 review, its README listed 60 entry points in 25 libraries and 138 proved statements. Its released proofs establish agreement between plain and sanitizer builds and exclude modeled errors on covered inputs. The plain build must stay within a 2 GiB memory budget for statements involving AddressSanitizer, or 16 GiB for those involving UndefinedBehaviorSanitizer. The repository says none of those released proofs establishes that the program always terminates. Its agreement statement excludes crashes, aborts, sanitizer failures and steps outside the model; it also compares observable behavior such as output and file contents. The 138 statement count is not a count of libraries or entry points.

The published proof set is tied to specific binary bytes, compiled for 64-bit RISC-V with musl. Its [checking documentation](https://github.com/theorem-labs/oss-verify-proofs/blob/main/docs/checking.md) describes how the tool verifies binary hashes, builds theorem statements and asks Rocq to check each submitted proof and its assumptions. BIG CHANGE inspected the published descriptions and artifacts; we did not execute the checker or reproduce a proof. The appendix's human expert assessment describes the proof text as unusually verbose and says it remains uncertain whether that style scales to more complex programs.

## Where the guarantee ends

Theorem's [model scope](https://github.com/theorem-labs/rocq-linux-process-semantics/blob/main/SCOPE.md) covers one thread, a defined set of Linux and RISC-V behavior, and specific process inputs. It omits such features as signal-handler execution and a full file-system model, and it lists assumptions about the surrounding process environment. The released agreement statements also have memory-budget premises: an input that pushes the plain build beyond the specified budget is outside their claim. Neither the reported 239 entry points nor the 60 publicly released entry points amount to verification of every path through each library.

A passed assertion has the meaning its author gave it. Sanitizers do not detect every memory error, and a no-crash property does not establish that every output is correct. Deployment can involve different processors, dynamic linking, other C libraries, callers and operating-system behavior. Applying a proof to a shipping product therefore requires checking its statement against the actual build and the model against the environment in which it runs.

## Sources & further reading

- [Anthropic's October 22 research account](https://www.anthropic.com/research/formal-verification) reports the full 239-entry-point effort, method and limits. It is the researchers' account, not an independent reproduction of the results.
- [Anthropic's technical appendix](https://www-cdn.anthropic.com/files/4zrzovbb/website/6867eadf760258fa8b42a504600cd3c036d16358.pdf) states the binary-level theorem and includes an expert reading of the proof style. It does not show that the model matches every deployed machine.
- [Theorem's public proof repository](https://github.com/theorem-labs/oss-verify-proofs) identifies the released subset, theorem forms, binary versions and checker procedure. We inspected its documentation and did not run the proofs.
- [Theorem's Linux process model scope](https://github.com/theorem-labs/rocq-linux-process-semantics/blob/main/SCOPE.md) lists supported systems, exclusions and assumptions that remain trusted when applying a proof to real software.

## Sources

- [LLMs are making formal software verification feasible at a much larger scale](https://www.anthropic.com/research/formal-verification) — Anthropic's account of the full research effort, method and limits; collaborator-reported findings, not an independent reproduction.
- [Appendix: LLMs are making formal software verification feasible at a much larger scale](https://www-cdn.anthropic.com/files/4zrzovbb/website/6867eadf760258fa8b42a504600cd3c036d16358.pdf) — States the binary theorem, below-64-MiB bound, LZO example and expert assessment; does not establish model fidelity for all deployments.
- [Theorem OSS Verify proof repository](https://github.com/theorem-labs/oss-verify-proofs) — Public release inventory: 60 entry points, 25 libraries, 138 proved statements; theorem boundaries and checking procedure. Documentation and artifacts inspected, checker not run.
- [LPS scope, assumptions and known gaps](https://github.com/theorem-labs/rocq-linux-process-semantics/blob/main/SCOPE.md) — Documents supported systems, one-thread scope, exclusions and unchecked environment assumptions; the proof release pins LPS commit f1006fe81783.