openai/NavierStokesAndEuler: Lean 4 certificates for finite time blowup

What the Lean certificates actually claim, and for whom

The repository is a proof artifact. Its README says it contains Lean 4 formalizations of the results in two OpenAI papers, "Finite time blowup for Navier-Stokes" and "Finite time blowup for the Euler equation". The audience is narrow: people who want to inspect the machine-checked version of those statements rather than the prose version.

The Navier-Stokes side covers two claims, one on the whole space and one on the torus. For every positive viscosity, the README states there exist smooth initial data and forcing for which no global smooth solution with uniformly bounded kinetic energy exists on R^3, and smooth periodic initial data and forcing for which no global smooth solution exists on the periodic torus. The README identifies these as alternatives (C) and (D) in the Clay Mathematics Institute's official problem description.

The Euler side is a different object. The README describes smooth, compactly supported, divergence-free initial velocity on R^3 whose solution to the unforced incompressible Euler equations develops a singularity in finite time, with the velocity's C^1 norm becoming unbounded near that time and the time integral of the vorticity's L^infty norm diverging. That is a statement about the inviscid equation, not a viscosity limit.

If you are looking for a solver, a discretization, or a numerical experiment, this is the wrong repository. Nothing in the README describes running a simulation.

How the Lean 4 and Mathlib layout is organized

The top-level entries tell you most of the architecture. There are two entry files, NavierStokes.lean and Euler.lean, each paired with a directory of the same name. ComparatorChallenges/ is a third directory, and formalization.yaml sits at the root alongside lakefile.toml, lake-manifest.json and lean-toolchain.

That split matters. The two .lean files are the import roots a reader would open first; the matching directories hold the supporting material behind them. formalization.yaml is the mapping between the informal statements in the papers and the formal declarations, which is the part a skeptical reader should read before anything else, because a proof is only as good as the statement it proves. lake-manifest.json pins the dependency set, and lean-toolchain pins the compiler, so a checkout is reproducible in the sense that the same Lean version and the same Mathlib revision are requested.

The README does not document the internal module structure of NavierStokes/ or Euler/, so how the argument is decomposed into lemmas is something you learn by reading the files. There is also no description of how long a full build takes, which for a Mathlib-dependent project is usually the first practical question.

Building the formalizations with Lake and the Mathlib cache

The README gives the toolchain as Lean 4.34.0-rc2, Mathlib and Lake, and assumes elan is already installed. The build is two commands, and the first one is not optional in practice: fetching the Mathlib cache avoids compiling Mathlib from source, which is the difference between a long wait and a very long one.

lake exe cache get
lake build

Run these from the repository root, since lakefile.toml lives there. The first command downloads prebuilt Mathlib artifacts; the second compiles the formalizations in this repository against them. On success you get exit code 0 with no error output, and the two root modules, NavierStokes.lean and Euler.lean, are the natural places to start reading.

If the build fails immediately, check the Lean version before anything else. lean-toolchain requests 4.34.0-rc2, and elan will try to fetch exactly that; a mismatched or unavailable toolchain is the most common early failure for a project pinned to a release candidate. The README does not document a rollback procedure or a fallback toolchain, so if 4.34.0-rc2 cannot be resolved on your machine, the README offers no alternative path.

Independent proof checking through Comparator

The most interesting part of this repository is the part that is least documented in the main README. It points to ComparatorChallenges/README.md for instructions on checking the formalizations with Comparator, but it does not summarize what Comparator is, what it checks, or what a passing run looks like. The ComparatorChallenges/ directory exists at the top level, so the files are there, but you have to go read them.

This is a deliberate and defensible design choice, and also a real cost. Lean proofs are checked by the Lean kernel, so a successful lake build already establishes that the terms typecheck. A second checker is about trusting the kernel and the toolchain less, or about catching statement-level mismatches between the paper and the formalization. Those are different questions, and the README does not say which one Comparator is being used to answer.

If your reason for being here is audit rather than curiosity, read ComparatorChallenges/README.md before you spend time on the main build. If it turns out to require infrastructure you do not have, that changes the plan, and you would rather learn it early.

Where this repository is the wrong tool

The README makes no claim of numerical results, benchmarks, or performance data, and none should be inferred. This is a formalization of existence and blowup statements, not a solver, so anyone hoping to reproduce a simulation from it will find nothing to run.

The scope is also narrower than the Clay problem as usually stated. The Navier-Stokes claims here are conditional in form: they assert the existence of particular smooth initial data and forcing that break global regularity, which the README maps to alternatives (C) and (D). That is not the same as a complete resolution of the Millennium Prize problem, and the README does not present it as one. Read the mapping in formalization.yaml rather than the headline.

The Euler result concerns the unforced incompressible equations. Anyone who wants a statement about the forced or viscous case should not read the Euler directory as covering it.

Finally, there is no release and no versioned artifact. The README lists no releases, so the only way to pin a state is a commit hash. If you need a fixed, citable artifact for a paper, that is on you to record.

How this differs from a Lean PDE analysis library

The obvious comparison is Mathlib itself, and the difference is one of purpose rather than overlap. Mathlib is a general library of mathematics in Lean, maintained as a shared dependency and consumed by many projects. This repository is a consumer of Mathlib: lake-manifest.json pins a Mathlib revision, and the code here is organized around two specific theorems rather than around reusable API.

That means the two are not substitutes. If you want lemmas about function spaces, measure theory or analysis to build your own formalization, you want Mathlib, and this repository will not help you beyond serving as an example of how one project structures a Mathlib-dependent development. If you want the two blowup statements checked, Mathlib alone gives you nothing, because the statements do not live there.

A second contrast is with the papers themselves. The PDFs are the human-readable argument; this repository is the machine-checked counterpart, and the two can drift. formalization.yaml is the place where that correspondence is asserted, which is why it is worth reading before the Lean files rather than after.

Maintenance, licensing and what a Lean pin costs you

The repository is not archived, and the last push was on 2026-09-10. That is recent enough that the pinned toolchain, Lean 4.34.0-rc2, is likely to still resolve, but it is a release candidate, and release candidates get superseded. The upgrade cost of a Lean development is dominated by Mathlib, not by the project's own files: bumping lean-toolchain means bumping the Mathlib revision in lake-manifest.json, and Mathlib does rename and restructure declarations. The README does not describe an upgrade procedure, so anyone who wants to move this forward is on their own.

Licensing is Apache-2.0, per the repository metadata and the LICENSE file at the top level. That is a permissive licence with an explicit patent grant, and it is compatible with the way Mathlib is licensed, which matters if you intend to combine the two. This is a description of the licence identifier, not legal advice; if you are redistributing modified versions, read the LICENSE file and the notices it requires.

There are no releases, so there is no changelog to consult. Track the main branch by commit hash if you need a stable reference.

Editorial conclusion

Adopt this repository if you need a machine-checkable artifact for the two blowup statements, or if you are auditing the papers and want a second, independent proof checker in the loop. Do not adopt it as a numerical Navier-Stokes solver, as a library of PDE analysis lemmas, or as a source of partial results: the README frames the contents as certificates for two specific claims. Before relying on it, run lake exe cache get and lake build to confirm the toolchain resolves, then work through ComparatorChallenges/README.md and check the formalization.yaml entries against the statements you actually care about.

Frequently asked questions

Official sources

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