OpenAI's Lean certificates attack two Clay alternatives, not the Millennium Prize itself

The claim is two numbered alternatives, stated in the README

The most useful thing in this repository is a sentence that many retellings of this work would leave out.

For every positive viscosity, two results are proved. On all of three-dimensional space, there exist smooth initial data and forcing for which no global smooth solution with uniformly bounded kinetic energy exists. On the periodic torus, there exist smooth periodic initial data and forcing for which no global smooth solution exists.

The README then names exactly which part of the official problem statement that addresses: alternative C, breakdown of solutions on all of three-space, and alternative D, breakdown on the torus. Both are labelled against the Clay Mathematics Institute's own problem document.

That precision is the whole story. The Millennium problem asks whether smooth, periodic, divergence-free initial data lead to a global smooth solution, among other conditions. Proving that solutions break down for specially constructed data answers a designated alternative, not the prize question. The repository makes that distinction explicit rather than leaving it to the reader, which is the opposite of how most announcements of this kind are written.

The Euler side is a singularity construction, not a smoothness theorem

The second formalization covers a different equation and states a different kind of result.

The construction is a smooth, compactly supported, divergence-free initial velocity field on three-space whose solution to the unforced incompressible Euler equations develops a singularity in finite time.

Two quantities are then named as the evidence, and they are what makes the statement precise. The velocity's norm measuring the value and first derivatives becomes unbounded as that time approaches. And the time integral of the vorticity's supremum norm diverges.

So this is an existence result: here is data, here is a finite time, here is the blow-up measured two ways. It is not a statement about whether solutions stay smooth in general, and the unforced qualifier matters because the Euler equations have no viscosity term to dissipate the energy that the Navier-Stokes formulation relies on.

The two formalizations sit side by side in the repository with separate top-level directories and separate entry files, which is a reasonable structure given they are independent results about different equations.

A second checker has to agree, not just the standard kernel

The verification story is the most interesting engineering content here, and it is a single short section.

The instructions for checking the formalizations do not say only to build them. They point at a separate project, a comparator, and its own instructions.

A Lean development is normally checked by compiling it: if the kernel accepts the proof and the library it depends on is trusted, the result holds. Lean also offers independent checking against the kernel, which catches bugs in elaborator machinery but still rests on the same library.

A comparator that replays a proof independently and compares the result is a different kind of check. It is aimed at the failure mode where a development compiles for reasons that are not the reasons you think, and it is the kind of rigour you would want precisely when a proof is being used as evidence in public.

That the comparator lives in its own top-level directory rather than inside the proofs, and that the README routes you to its documentation instead of duplicating it, keeps the boundary clean.

A release candidate of the toolchain is pinned in the repository

The build section names three things and one of them is a pre-release.

The project targets a specific Lean 4 version, and that version string ends in a release candidate suffix rather than a final release. There is a file at the repository root pinning the toolchain, which is how Lean projects make a development reproducible: the version is not a suggestion, it is what the build will use.

Alongside it sit the mathematics library and the build tool. Fetching the library cache and building are two commands.

Pinning a release candidate is defensible for a formalization that has to keep compiling against a moving library, and it is also a real constraint. Anyone reproducing this needs that exact toolchain, not the current stable one, so the release the project names is a prerequisite rather than a convenience.

Fetching the library cache and building are two commands:

lake exe cache get
lake build

The cache step matters for a second reason: the library is large, and the instruction to fetch it explicitly is the difference between a build that takes minutes and one that takes hours.

The repository is small because the proofs are the artifact

The top-level listing is short and shaped the way you would expect a formalization to be.

There is one directory per result, plus a top-level file for each, so a reader can navigate to one formalization without loading the other. There is a directory for the independent checker, a directory for the build configuration, and a machine-readable description file. There is a licence, an ignore file, and the pinned toolchain.

What is absent is as informative as what is present. No scripts directory, no continuous integration configuration at the root, no examples directory, no documentation site. This is not an application with a build pipeline and a deployment story. It is a set of proofs plus the metadata needed to check them.

The papers and a blog post are linked from the README rather than vendored, so the repository points at the human-readable arguments and holds the machine-checkable parts. That split is the right one for this kind of work, and it is why the repository can be small without being incomplete.

Licensing is permissive and the maths is the hard part

The licence is the permissive one, which is worth a sentence because the content is unusual.

A formalization of a theorem carries the theorem's method with it. Anyone can read the proof, and a permissive licence lets them build on it, extend it, or machine-check variations of it. That is what makes this kind of release useful to the formal mathematics community rather than only to its authors.

The repository is not archived and the most recent push is dated in September 2026, so the work is being touched.

What the repository is not is a complete answer to either question. The Navier-Stokes side addresses designated alternatives rather than the existence question the prize asks. The Euler side constructs a singular solution rather than classifying smooth ones. And the results are presented as accompanying the papers, with the papers linked, which frames the formalizations as verification of published arguments rather than as standalone new results.

Editorial conclusion

Treat this as evidence of machine proof engineering rather than as a resolution of the prize problem, because that is what the repository itself claims. The formalizations cover two numbered alternatives in the official problem statement, which is a different and narrower result, and the Euler construction is a singularity result rather than a smoothness theorem. What is genuinely notable is the verification path: an independent comparator alongside the standard kernel, which means a second implementation has to agree. If you want to read one thing here, read the two result statements before the build instructions, because everything else in the repository is tooling.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openai/NavierStokesAndEuler on GitHub
4. README