Which other projects did Claude formally verify besides OSS-Fuzz targets?

Anthropic's formal verification post lists several case studies. Claude wrote a spec of RFC 1950 and proved the Linux kernel's zlib meets it at the x86 binary level. It wrote a Python-subset interpreter in Rust, proved with Verus to follow CPython semantics, matching CPython on 99.95% of 1.7 million random programs. It also proved libc++'s red-black tree stays logarithmic in depth for cpp-httplib.

Are the Claude-written proofs available to download?

Anthropic and Theorem published a subset of the proofs in the theorem-labs/oss-verify-proofs repository and the RISC-V and Linux process semantics in theorem-labs/rocq-linux-process-semantics. Anthropic says it is not releasing proofs that could reveal unpatched bugs; it publishes the completed proofs for fuzz tests that needed no patches and the specs for tests it could not prove.

Can open-source maintainers get their project verified the same way?

Theorem runs OSS Verify, a free formal verification service for qualifying open-source projects, modeled on OSS-Fuzz. Core maintainers open a pull request with a project.yaml, Dockerfile and build.sh, and the build must produce static riscv64 binaries. Bugs found are disclosed privately to maintainers, and Theorem notes the findings and patches are AI-generated.

What are the limits of these formal proofs?

Anthropic says formally verified does not mean bug-free. The proofs assume a single-threaded static binary with a fixed memory budget on a RISC-V CPU under Linux, which differs from typical glibc and dynamic-linking deployments. They also trust the RISC-V, Linux and Rocq semantics, AddressSanitizer does not catch every memory bug, and callers can still misuse a library.

Anthropic · 2026-10-22 · major

Claude proves 239 OSS-Fuzz targets never crash — formal verification at scale

Anthropic and Theorem used Claude to write machine-checked Rocq proofs that 239 fuzz-test entry points in 123 open-source libraries never crash on any input under 64 MB, finding and patching hundreds of bugs along the way.

Anthropic research post header for LLMs making formal software verification feasible at scale

Claude wrote machine-checked proofs that real open-source binaries never crash, a job that once took experts years.

Quick facts

Team	Anthropic Frontier Red Team with Theorem
Proven	239 fuzz entry points, 123 libraries
Property	No crash for any input under 64 MB
Proof checker	Rocq
Proof size	About 180M lines of Rocq in total
Time taken	A few weeks
Released	Proof subset + RISC-V/Linux semantics on GitHub

What is it?

Anthropic's Frontier Red Team and the startup Theorem had Claude write formal correctness proofs for real open-source software. The main result covers 239 fuzz-test entry points across 123 libraries from Google's OSS-Fuzz project: each is proven never to crash, with no memory-safety error or failed assertion, for any input under 64 MB.

How does it work?

Each fuzz test becomes a spec that says "this test always passes", stated over a general model of a RISC-V program running on Linux. Claude writes the proof at the level of the compiled RISC-V instructions, and the Rocq proof checker verifies it, so readers only need to trust Rocq and the published semantics. A typical proof is about 600,000 lines. To stop reward hacking, such as rewriting a program so it trivially never crashes, patches were penalized, logged and audited.

Why does it matter?

Proving software correct has usually needed years of expert work per project. Here the proving itself found and fixed hundreds of bugs, including a counter underflow in a decompressor and a rediscovered libexpat CVE. The post also reports that Opus 5.5 proved half of 36 small tasks with about 40% fewer tokens than Opus 5. Anthropic notes that "formally verified" still does not mean bug-free: the result depends on the trusted semantics and a static-binary, single-threaded setup.

Who is it for?

security researchers, open-source maintainers, formal-methods engineers

Frequently asked questions

Which other projects did Claude formally verify besides OSS-Fuzz targets?: Anthropic's formal verification post lists several case studies. Claude wrote a spec of RFC 1950 and proved the Linux kernel's zlib meets it at the x86 binary level. It wrote a Python-subset interpreter in Rust, proved with Verus to follow CPython semantics, matching CPython on 99.95% of 1.7 million random programs. It also proved libc++'s red-black tree stays logarithmic in depth for cpp-httplib.
Are the Claude-written proofs available to download?: Anthropic and Theorem published a subset of the proofs in the theorem-labs/oss-verify-proofs repository and the RISC-V and Linux process semantics in theorem-labs/rocq-linux-process-semantics. Anthropic says it is not releasing proofs that could reveal unpatched bugs; it publishes the completed proofs for fuzz tests that needed no patches and the specs for tests it could not prove.
Can open-source maintainers get their project verified the same way?: Theorem runs OSS Verify, a free formal verification service for qualifying open-source projects, modeled on OSS-Fuzz. Core maintainers open a pull request with a project.yaml, Dockerfile and build.sh, and the build must produce static riscv64 binaries. Bugs found are disclosed privately to maintainers, and Theorem notes the findings and patches are AI-generated.
What are the limits of these formal proofs?: Anthropic says formally verified does not mean bug-free. The proofs assume a single-threaded static binary with a fixed memory budget on a RISC-V CPU under Linux, which differs from typical glibc and dynamic-linking deployments. They also trust the RISC-V, Linux and Rocq semantics, AddressSanitizer does not catch every memory bug, and callers can still misuse a library.

Try it

https://github.com/theorem-labs/oss-verify-proofs