# FLT is a proof of Fermat's Last Theorem being formalised in Lean, and it is unfinished

> This is the Imperial College London project that turns the Wiles and Taylor-Wiles proof of Fermat's Last Theorem into machine-checked Lean code, led by Kevin Buzzard and funded by an EPSRC grant until September 2029. The repository badges say it plainly: the website is ready, the documentation passes, and both the blueprint and the paper are still work in progress.

**ImperialCollegeLondon/FLT** — Ongoing Lean formalisation of the proof of Fermat's Last Theorem

- Repository: https://github.com/ImperialCollegeLondon/FLT
- Website: https://imperialcollegelondon.github.io/FLT/
- Stars: 1,053 · Forks: 172
- Language: Lean
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/imperialcollegelondon-flt

## The claim being checked is the one Wiles and Taylor proved

The project description is one line and it does not hedge. It is an ongoing multi-author open source project to formalise a proof of Fermat's Last Theorem in the Lean theorem prover.

The word that matters is formalise. The mathematics is not being invented here. The route the project takes was planned out essentially entirely by Richard Taylor in discussions with Buzzard, and the README describes it as a modern variant of the original Wiles and Taylor-Wiles proof, borrowing heavily from the ideas of Khare and Wintenberger. The blueprint is where the mathematics is set out, and it is the recommended starting point for anyone who wants the details behind the proof.

That distinction is the whole point of the project. Fermat's Last Theorem is already proved in the sense that a human being has written down an argument that the field accepts. What is missing is a machine-checkable version of it, where every step is verified by a small trusted kernel rather than by a reader who might skip a line. A Lean formalisation produces that: a file where the statement of the theorem and every intermediate lemma are checked by the elaborator.

The scale is what sets it apart. This is a document-scale formalisation effort, not a library, and the repository layout says so. At the top level there is FLT.lean and a FLT/ directory for the mathematics, FLTTest.lean and FLTTest/ for the tests, a blueprint/ directory and a blueprint-verso/ directory for the written plan, a docs/ directory for the generated documentation, and blog.md, GENERAL.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md and CITATION.bib alongside them.

The multi-author framing also matters. A formalisation of this size is not one person's typing exercise, it is a long campaign in which different mathematicians formalise different parts and the pieces have to fit.

## The blueprint is the plan, and the badges say it is still a plan

The badge row at the top of the README is the most honest summary of the project state, and it is worth reading carefully because the labels are not all the same.

The website badge says ready, the documentation badge says passing, and the blueprint badge says WIP, and so does the paper badge. In other words, the parts that are infrastructure are working, and the two things that constitute the mathematics, the blueprint of the proof and the paper generated from it, are still work in progress.

The blueprint is a blueprint in a specific technical sense. It is a structured document in which each mathematical statement is tagged with the name of the Lean declaration that will prove it, so the document and the code are cross-linked in both directions. A reader can follow the mathematics in the blueprint and see the Lean file that implements each piece, and a reader can look at a Lean file and find the statement it is proving. The blueprint/ directory holds the source, blueprint-verso/ holds the machinery that renders it, and blueprint.pdf is the paper, which the badge says is still being written.

The docs/ directory is separate and is marked as passing, and the documentation badge points at it, which suggests the API documentation for the project is in a better state than the proof itself. That is the normal shape for a formalisation project: the plumbing of the codebase is settled, and the mathematics grows in the gap between the blueprint and the code.

For a reader evaluating whether to join, this is the most useful thing in the repository, because it locates the work precisely. A task that says implement this lemma of the blueprint is a well-defined task, and the repository has a 2026_EPSRC_TCC_course/ directory at the top level, which suggests the project also runs structured teaching around the material.

## Funding runs to September 2029, which sets the project's horizon

The project is currently being led by Kevin Buzzard, and until September 2029 it is being funded by grant EP/Y022904/1, awarded by the EPSRC. The project is hosted at Imperial College London, and the README says Buzzard would like to extend many thanks to both institutions for their ongoing support of this nonstandard research.

That phrasing is doing some work. Nonstandard research is the term of art for a project that does not fit the usual funding categories, and the sentence is an acknowledgement that this kind of work is not a normal thing for a research council to fund and that it is being paid for on the understanding of a long horizon.

The date is the important part. September 2029 gives roughly three years from the point of writing, and a formalisation of this size is measured in years, so the funding period is a statement about scale. It is also a boundary: the README describes the funding as running until that date, not as open ended, and a reader considering a long involvement should understand that as the shape of the commitment rather than assume indefinite support.

The hosting arrangement is worth noting too. Imperial College London is providing the institutional home, and the project is explicitly multi-author and open source, which is what makes it possible for contributors outside the funded group to work on it.

Two other pieces of infrastructure point the same way. There is a CITATION.bib file at the root, so the work is set up to be cited, and there is a.gitpod.yml together with a Gitpod Ready-to-Code badge, which means someone with no Lean setup can open the project in a browser-based development environment and start reading or editing.

## The build is Lake, and the toolchain is pinned in the repository

The Lean project layout is visible in the file names, and it follows the standard Lean 4 conventions.

```console
FLT.lean
FLTTest.lean
blueprint/
docs/
lakefile.toml
lake-manifest.json
lean-toolchain
tasks.py
```

The lakefile.toml is the project definition and lake-manifest.json records the pinned dependency versions, and the lean-toolchain file pins the exact Lean version the project builds against. That pin is the reason the toolchain file matters more than usual here: a formalisation that compiles against one Lean version and not the next is a project that stops building for everyone but the author, so the file is checked in and the CI reads it.

The tasks.py file sits alongside the Lake setup, which is the usual pattern for wrapping the build in a Python-driven task runner so that contributors have one entry point for building, testing and generating the documentation and the blueprint rather than memorising a list of lake invocations. There is also a scripts/ directory for the rest of that tooling, a .vscode/ directory for editor configuration, and a .github/ directory for the workflows.

The test story is split across FLTTest.lean and the FLTTest/ directory, which is a pattern worth noticing. For most Lean projects, the test file is a smoke test that the module still imports. In a formalisation, tests can also carry mathematical content, and a project of this size keeps them separate for a reason: the file that imports everything is where you check that the whole tree still builds, and the tests themselves are where the mathematical checks live.

None of this is documented in the README, so it is worth reading the CONTRIBUTING.md before trying to build, and the tasks.py file itself is the fastest way to see what the project expects a contributor to run.

## Formalising a proof is a different job from proving it

There is a real alternative here, and it is the way the mathematics was done for three centuries: write the proof on paper, have it refereed, and rely on readers to check it.

The difference in approach is where the checking happens. In a paper proof, correctness depends on every reader verifying every step, and the errors that survive are the ones a careful reader did not notice. In a formal proof, the statement is checked by a small trusted kernel, and the effort moves from reading and trusting to formalising, which is where the machine earns its keep. A formalisation also has to say more: it forces you to make explicit definitions that a paper can leave implicit, and it removes the step where a proof says something is straightforward and the reader accepts it.

The cost is enormous, and it is worth being blunt about the ratio. FLT is one theorem, and the paper proof is a few hundred pages with a well-known difficulty around modularity and Galois representations. Turning that into Lean means writing thousands of lines that mostly consist of bookkeeping, typeclass instances and auxiliary lemmas that exist only to make the machine accept a step. The blueprint exists precisely because the mathematical content and the Lean content are not the same shape, and a reader needs the blueprint to follow along.

The second alternative is to use an existing automated theorem prover and hope it finds the proof. That is a different project with a different failure mode, and it is not what is happening here: this is a translation of a known human proof into a form the kernel can check.

For an adopter, the practical question is what you want from it. If you want a verified artefact to cite, that is years away. If you want to work on formal methods on a real, hard, famous theorem, with a blueprint that tells you what to do and a community that has been doing it for years, that is available now.

## Apache-2.0, a release candidate train, and an open contribution path

The licence is Apache-2.0, with the LICENSE file at the repository root, so the code can be used, modified and redistributed, including commercially, provided the notice and licence conditions are met. That is a licensing fact rather than legal advice, and for an academic project it is the permissive end of the scale.

The release history shows a project that versions continuously and ships candidates. The recent tags are v4.35.0-rc3 on 2026-09-26, v4.35.0-rc2 on 2026-09-24 and v4.35.0-rc1 on 2026-09-23, so three release candidates for one version inside four days, which is the pattern of a project where the version number tracks the state of the proof rather than a periodic software release.

The repository is not archived, the default branch is main, and the last push was on 2026-10-10, so the work is live and current. The activity is consistent with the funding period and with a multi-author project with an established contribution flow.

The contribution path is documented rather than improvised. Information on how to contribute is in CONTRIBUTING.md, the general background material, including what Fermat's Last Theorem and Lean are and why the project exists, is in GENERAL.md, and there is a CODE_OF_CONDUCT.md for the community side. The blog.md file at the root suggests the project also publishes progress notes, which is how a project of this size tells its contributors where the gaps are.

The whole design is arranged to make the next contribution possible. The blueprint names the missing lemmas, the Lean tree holds what has been proved, the toolchain file makes the build reproducible, and the test directory checks the parts that can be checked. For a volunteer, that is the difference between a research programme and a repository you cannot get running.

## Conclusion

FLT fits a formal methods engineer who wants to work on a proof of the highest profile in mathematics, and a mathematician who wants to see how much of an argument can be reduced to a kernel check. It does not fit anyone looking for a completed proof, because both the blueprint and the paper are marked work in progress. Before joining, read GENERAL.md for the background, the blueprint for the mathematics, and CONTRIBUTING.md for the workflow, then check that the Lean toolchain pinned in lean-toolchain is the one your setup can install, because the project is a long campaign rather than a sprint.

## FAQ

### What is the Imperial College London FLT project?

It is an ongoing multi-author open source project to formalise a proof of Fermat's Last Theorem in the Lean theorem prover, led by Kevin Buzzard and hosted at Imperial College London. The route taken was planned essentially entirely by Richard Taylor in discussions with Buzzard, as a modern variant of the Wiles and Taylor-Wiles proof.

### Is the Fermat's Last Theorem proof in Lean finished?

No. The badges in the README mark the website as ready and the documentation as passing, while both the blueprint and the paper are marked WIP. The project is described as ongoing, and the recent release tags are release candidates for v4.35.0.

### How is the FLT project funded?

It is funded by grant EP/Y022904/1, awarded by the EPSRC, until September 2029, and hosted at Imperial College London. The README describes it as nonstandard research and notes the ongoing support of both institutions.

### What is the blueprint in the FLT repository?

The blueprint is the mathematical plan of the formalisation, where statements are paired with the Lean declarations that will prove them, and it is the recommended starting point for understanding the mathematics. The blueprint/ directory holds its source, blueprint-verso/ holds the rendering machinery, and blueprint.pdf is the paper.

### How do I contribute to the FLT formalisation?

Information on how to contribute is in CONTRIBUTING.md, the background on the project is in GENERAL.md, and the lake build is defined by lakefile.toml with dependencies pinned in lake-manifest.json and the Lean version pinned in lean-toolchain. A .gitpod.yml is included with a Gitpod Ready-to-Code badge so you can open the project in the browser before setting up a local toolchain.

## Sources

- [ImperialCollegeLondon/FLT on GitHub](https://github.com/ImperialCollegeLondon/FLT)
- [License: Apache-2.0](https://github.com/ImperialCollegeLondon/FLT/blob/main/LICENSE)
- [Project website](https://imperialcollegelondon.github.io/FLT/)
- [README](https://github.com/ImperialCollegeLondon/FLT/blob/main/README.md)
- [Releases](https://github.com/ImperialCollegeLondon/FLT/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imperialcollegelondon-flt