--- title: LLMs are making formal software verification feasible at... description: Claude formally proved that 239 fuzz-test entry points across 123 open-source libraries never crash on any input under 64 MB, working at the compiled RISC-V... canonical: https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: LLMs are making formal software verification feasible at a much larger scale | daily.dev og:description: Claude formally proved that 239 fuzz-test entry points across 123 open-source libraries never crash on any input under 64 MB, working at the compiled RISC-V... og:url: https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku og:image: https://api.daily.dev/og/posts/oaRwz7ikU.png og:image:alt: LLMs are making formal software verification feasible at a much larger scale og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # LLMs are making formal software verification feasible at a much larger scale **[Hacker News](https://daily.dev/sources/hn)** · 18 min read · 0 upvotes · 1 comments ## Summary Claude formally proved that 239 fuzz-test entry points across 123 open-source libraries never crash on any input under 64 MB, working at the compiled RISC-V assembly level. The proofs, built in collaboration with Theorem, total about 180 million lines of Rocq code and cover memory-safety and other properties for binaries with a median length of 18,000 RISC-V instructions. While writing them, Claude patched bugs including a counter underflow leading to an out-of-bounds write and a rediscovery of CVE-2026-56132 in libexpat. Opus 5.5 proves half of 36 small verification tasks with about 40% fewer tokens than Opus 5, and letting agents share proofs cut token use by 17%. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How many open-source libraries did Anthropic's Claude formally verify at the binary level? Claude proved memory-safety and crash-freedom properties for 239 fuzz-test entry points across 123 open-source libraries from Google's OSS-Fuzz initiative. The proofs operate on compiled RISC-V assembly instructions rather than source code, totaling about 180 million lines of Rocq proof code, with a typical proof running around 600,000 lines for binaries with a median length of 18,000 RISC-V instructions. _Developers evaluating AI for security hardening can follow formal verification breakthroughs like this on daily.dev._ ### What bugs did AI-assisted formal verification find that fuzz testing missed? Claude found a counter underflow in a decompressor causing an out-of-bounds write on roughly 20 MB inputs with a rare layout, an out-of-bounds read in an image decoder needing a 64 MB input and over 2 GB of memory, a logic bug where file-loading restrictions weren't enforced, and a rediscovery of CVE-2026-56132 in libexpat requiring deeply nested input. These were hard for fuzzers because fuzz inputs are typically capped around 1 MB. _Teams hunting for elusive edge-case bugs can track new fuzzing and verification techniques on daily.dev._ ### How much faster is Anthropic's Opus 5.5 model at formal verification tasks compared to Opus 5? Opus 5.5 proves half of a 36-task benchmark built from real OSS-Fuzz code using about 40% fewer tokens than Opus 5. Separately, letting multiple verification agents share and reuse each other's proofs in a common workspace cut token usage by 17%, with some agents succeeding on tasks they had previously failed solo. _Developers comparing model versions for cost and efficiency gains can follow updates like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 122 comments across hackernews (as of 2026-10-23). **TL;DR:** Reactions mix genuine excitement about scaling formal verification with LLMs against persistent skepticism about whether proofs actually match real-world intent, with a long tangent debating whether this pushes software toward declarative/provable languages. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Several practitioners report real success using LLM-assisted proofs (Lean/Rocq/Coq) to verify equivalence between rewritten and original code, catching subtle bugs like floating-point platform differences. - Proving a fuzz test can never crash gives stronger guarantees than fuzzing alone since it covers the entire input space, not just sampled cases. - Some see this as a path toward a future where formally verified code becomes default practice, especially for security-critical surface area. - Practitioners doing similar work at the LLVM IR or binary level confirm it's technically feasible and already useful for SIMD/CUDA equivalence proofs. **The pushback** - A proof is only as good as the model/spec behind it — if the formal model diverges from the actual code or compiler, you can 'prove' something that isn't really your program. - Skeptics question whether this is true formal verification against user intent versus just checking equivalence/crash-freedom, calling some marketing claims about a formally verified Python interpreter misleading or a 'subset' that doesn't represent real Python. - Concerns that agents hit an abstraction/complexity wall with verbose proof styles that may not scale to more complex programs without better modular reasoning. - Some argue this is overhyped PR from Anthropic ('marketorials') and that unit tests/proofs written by the same system that wrote the code are inherently biased toward passing. - A philosophical objection invoking the halting problem to argue that no proof process can guarantee bug-free software for nontrivial systems, though others push back that this misapplies the theorem to specific real programs. **By community** - hackernews (mixed): Discussion splits between enthusiastic practitioners sharing real proof-assistant workflows and skeptics questioning whether these proofs meaningfully verify intent, compiler correctness, or scale beyond a complexity wall. **Hottest debate:** Whether formally proving crash-freedom or equivalence against a model actually constitutes meaningful verification of real-world software behavior, or just moves the trust problem up one layer to the spec/model itself. **Open questions** - How do you verify that a custom compiler translating source code (Rust/C) into a proof language like Lean is itself correct? - Can agents discover better modular proof abstractions needed to scale past the complexity wall seen in verbose proof styles, or does this require expert proof engineers? - Will increased formal verification capability actually change industry practice, or will the productivity gains just be spent shipping more unvetted code faster? **Highlights** > That's not what they did. What they did is tried to prove that the conventional fuzzer won't find crashes. Where they found counterexamples, they fixed the bug and tried again. In essence, a fuzzer takes random samples out of a space of possible inputs that could crash. They proved that nothing in the space of possible inputs could crash. This is a strictly more powerful result than a fuzzer could give you. > — [btilly on hackernews](https://news.ycombinator.com/item?id=50203021) > For those skeptical, I've had decent success using formal verification for my Rust rewrite of Postgres. I wrote a compiler that can translate both Rust and C code into Lean. Once those two functions are in Lean, I have an LLM write a Lean proof that they behave identically. So far, I've proven that about 12% of the code behaves the same when executed single-threaded. That works out to roughly 70k lines of C code. This has found very minor differences in behavior, such as how floating-point operations across platforms can produce different results. I'm working on figuring out how to scale this up, but I don't see any fundamental limitation that would prevent this from scaling up further. > — [malisper on hackernews · 3 comments](https://news.ycombinator.com/item?id=50203167) > Formal verification against what? The elusive 100%-coverage formal spec that covers every intended and unintended input, the interests of every stakeholder, and every possible user behavior? In the vibecoding era? No, the page has the decency to acknowledge this doesn't exist. In the end, they settle on finding crashes with a conventional fuzzer, fixing crashes, and then... writing a formal proof that the crash is fixed? That seems... pretty pointless? Am I missing something here? > — [pinevale on hackernews · 5 comments](https://news.ycombinator.com/item?id=50202940) > Talk is cheap, show me the code. Claude generated a formally verified Python interpreter in Rust? Bullshit. Anthropic would have published it if they did, like that dogshit C compiler publicity stunt. That they won't even show it indicates that this is so misleading as to be a lie. They generously give themselves the grace of describing it as a "subset" of Python interpreter, and I believe them -- I can formally verify a "subset" of Python quite easily, but nobody will be impressed when they look at what that really means. Why was it tested with "1.7 million randomly generated" Python programs and not any real-world Python programs that already existing? Because the subset doesn't cover what anybody would consider to actually be Python. > — [anonymous908213 on hackernews · 1 comments](https://news.ycombinator.com/item?id=50203692) > The halting problem applies when you are trying to check the properties of arbitrary programs. However, we are not writing arbitrary programs, we are writing very specific (hopefully useful) programs. The two are very different. Pop-sci explanations of the halting problem have probably done incredible damage to formal verification as a whole. Mostly because it makes people with only the most cursory understanding of it go "why bother, it won't work anyway." > — [3uruiueijjj on hackernews · 1 comments](https://news.ycombinator.com/item?id=50204306) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50202217) · 199 points · 122 comments ## Community discussion Top comments from developers on daily.dev. **@tangweikun** · 0 upvotes > The part that sold me isn't the 180M lines of Rocq — it's that the proof loop rediscovered CVE-2026-56132 and a real counter underflow along the way. Verification that only re-confirms tests you already wrote is theater; verification that finds bugs you didn't know existed is the product. ## Similar posts on daily.dev - [Lean proved this program was correct; then I found a bug.](https://daily.dev/posts/lean-proved-this-program-was-correct-then-i-found-a-bug--n0f0rtus1) · Lobsters · 0 upvotes · 0 comments - [Fragments: October 4](https://daily.dev/posts/fragments-october-4-lzsrirk3s) · Martin Fowler · 0 upvotes · 0 comments - [A blueprint for formal verification of Apple corecrypto](https://daily.dev/posts/a-blueprint-for-formal-verification-of-apple-corecrypto-nstkdfael) · Hacker News · 5 upvotes · 0 comments --- Tags: [#claude](https://daily.dev/tags/claude) [View this post on daily.dev](https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"LLMs are making formal software verification feasible at a much larger scale","url":"https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku"},"datePublished":"2026-10-23T01:27:03.229Z","dateModified":"2026-10-23T04:50:08.250Z","description":"Claude formally proved that 239 fuzz-test entry points across 123 open-source libraries never crash on any input under 64 MB, working at the compiled RISC-V...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3b03b6109892ec082b0fcdafc62eccb1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3b03b6109892ec082b0fcdafc62eccb1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"claude","timeRequired":"PT18M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"LLMs are making formal software verification feasible at a much larger scale"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku","comment":[{"@type":"Comment","text":"The part that sold me isn’t the 180M lines of Rocq — it’s that the proof loop rediscovered CVE-2026-56132 and a real counter underflow along the way. Verification that only re-confirms tests you already wrote is theater; verification that finds bugs you didn’t know existed is the product.","datePublished":"2026-10-23T16:29:00.521Z","url":"https://daily.dev/posts/oaRwz7ikU#c-kSq497ApU","author":{"@type":"Person","name":"Neo Tang","url":"https://daily.dev/tangweikun","image":"https://lh3.googleusercontent.com/a/ACg8ocI9RNUFuBT-pF6eofRaRVlYqDYEXz2h85hTtVixlUKUOsr2MlVO=s96-c"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/llms-are-making-formal-software-verification-feasible-at-a-much-larger-scale-oarwz7iku#faq","mainEntity":[{"@type":"Question","name":"How many open-source libraries did Anthropic's Claude formally verify at the binary level?","acceptedAnswer":{"@type":"Answer","text":"Claude proved memory-safety and crash-freedom properties for 239 fuzz-test entry points across 123 open-source libraries from Google's OSS-Fuzz initiative. The proofs operate on compiled RISC-V assembly instructions rather than source code, totaling about 180 million lines of Rocq proof code, with a typical proof running around 600,000 lines for binaries with a median length of 18,000 RISC-V instructions. Developers evaluating AI for security hardening can follow formal verification breakthroughs like this on daily.dev."}},{"@type":"Question","name":"What bugs did AI-assisted formal verification find that fuzz testing missed?","acceptedAnswer":{"@type":"Answer","text":"Claude found a counter underflow in a decompressor causing an out-of-bounds write on roughly 20 MB inputs with a rare layout, an out-of-bounds read in an image decoder needing a 64 MB input and over 2 GB of memory, a logic bug where file-loading restrictions weren't enforced, and a rediscovery of CVE-2026-56132 in libexpat requiring deeply nested input. These were hard for fuzzers because fuzz inputs are typically capped around 1 MB. Teams hunting for elusive edge-case bugs can track new fuzzing and verification techniques on daily.dev."}},{"@type":"Question","name":"How much faster is Anthropic's Opus 5.5 model at formal verification tasks compared to Opus 5?","acceptedAnswer":{"@type":"Answer","text":"Opus 5.5 proves half of a 36-task benchmark built from real OSS-Fuzz code using about 40% fewer tokens than Opus 5. Separately, letting multiple verification agents share and reuse each other's proofs in a common workspace cut token usage by 17%, with some agents succeeding on tasks they had previously failed solo. Developers comparing model versions for cost and efficiency gains can follow updates like this on daily.dev."}}]} ```