The Collatz Conjecture Was "Refuted" — Then the Proof Fell Apart
On July 30, 2026, sensational news broke: Ramana Kumar had proved the negation of the Collatz conjecture. The proof was checked in Lean and double-checked with the independent Nanoda type checker. The only problem? The proof was wrong, exploiting a bug in the Lean kernel. Nanoda missed it too.
Lawrence Paulson, a professor at the University of Cambridge and creator of Isabelle, dissects the incident in a blog post titled "Why is it all in the kernel?" He doesn't gloat — soundness bugs have hit Isabelle too — but he draws sharp lessons about proof objects, kernel design, and the culture of proof assistants.
The Bug: Nested Inductive Types in the Kernel
The exact nature of the Lean bug isn't disclosed, but rumor has it that nested inductive types in the kernel were the culprit. Paulson notes that Rocq (formerly Coq) has suffered soundness bugs from pattern matching with recursive functions in the kernel. These features are built into the kernel for convenience, but they expand the trusted computing base. Every extra feature is a potential source of unsoundness.
The Dead Weight of Proof Objects
Paulson's central argument: proof objects are unnecessary. Robin Milner designed ML specifically for proof assistants, using abstract types to confine the rules of inference to a secure kernel. The kernel acts as an API for creating theorems, and the rest of the program can't violate soundness.
Yet the community has "doubled down" on storing proof objects, treating them as certificates that can be checked independently. But Paulson knows of no instance where an independent checker caught a soundness error that passed the kernel. In the Collatz case, Nanoda was fooled too.
He compares proof objects to towing a spare car behind you everywhere — a massive memory burden that doesn't even work when you need it. Worse, the burden of proof objects may be the very cause of the breakdown: "it is only the proof calculi that have proof objects that seemingly need to put everything into the kernel."
Theft vs. Honest Toil
Paulson contrasts two approaches to building proof assistants. "Theft" means postulating powerful features directly in the kernel. "Honest toil" means starting with minimal axioms and deriving everything else.
He quotes Bertrand Russell: "The method of 'postulating' what we want has many advantages; they are the same as the advantages of theft over honest toil."
Set theory and simple type theory are examples of honest toil. Set theory gives you a few principles for introducing sets: unions, separation, pairing, replacement. Simple type theory gives you a bit of logic and λ-calculus. From these, you can define inductive definitions, recursive functions, records, pattern matching, and partial functions — all outside the kernel, so they can't introduce contradictions.
The 1980s: Paulson's Honest Toil in MLTT
Paulson recounts his experience in the 1980s working with Martin-Löf type theory (MLTT). The theory only supported primitive recursion, but higher types allowed more powerful forms. He laboriously defined a system of combinators within MLTT to express a vast space of terminating recursive functions.
He didn't realize the game was rigged. The accepted solution was to extend MLTT with a general notion of recursion — simple and elegant. His work was cited as "Paulson extended MLTT with recursion," but he insists that's not what he did. He obtained recursion through honest toil, and nobody understood it.
What Does Honest Toil Look Like?
Paulson explains the practical steps for building recursive structures without kernel extensions.
For recursive data types, an inductive definition can be transformed into a monotone operator on sets. The least fixed point gives you an inductive definition; the greatest fixed point gives co-inductive. In Isabelle, these constructions are handled generally and sophisticatedly through bounded natural functors.
For recursive functions, the process is tedious. You start with a well-founded relation and prove the existence of the function by well-founded induction. Paulson's earlier MLTT work proved helpful. Isabelle/HOL now supports recursive function definitions in great generality, including pattern matching and termination checking — all safely outside the kernel.
The Irony: Proof Objects Undermine Soundness
Paulson points out the irony: proof objects are touted as increasing soundness, but the opposite is true. By pushing features into the kernel to support proof objects, you increase the chance of bugs. He recommends HOL Light or HOL4 for maximum soundness, noting that Isabelle has had fewer bugs than "certain other systems" (likely Lean and Coq).
What Developers Should Take Away
This isn't just academic. If you're building tools that rely on proof assistants — formal verification, smart contracts, security proofs — you need to understand the trust model. A proof checked by Lean is only as trustworthy as the kernel's implementation. Independent checkers can miss bugs too.
Paulson's advice: prefer systems with minimal kernels. HOL Light and HOL4 have the smallest trusted bases. Isabelle, while not minimal, has a strong track record. Lean's kernel is more complex, and this bug shows the risk.
For those designing proof assistants or formal systems, consider Paulson's honest toil approach. Define features outside the kernel where possible. The cost is development effort, but the payoff is soundness.
The Future of Proof Assistants
Paulson doesn't call for abandoning Lean or proof objects entirely. He acknowledges that soundness bugs can happen anywhere. But he urges the community to reconsider the trend toward complex kernels. The Collatz incident is a wake-up call: even a proof checked by two systems can be wrong.
As a developer, you should question the tools you trust. Formal verification is powerful, but it's not magic. Understand the kernel, the proof object format, and the limits of independent checking. And if you're building a proof assistant, consider the humble path of honest toil — even if it means breaking rocks.
