∀
Feasibility assessment
We read your paper, check what Mathlib already covers, find the hardest lemma, and tell you whether a full formalization is realistic, how long it should take, and what it will cost. Fixed fee, quoted up front.
Lean 4 · Mathlib · Machine-checked
Making correctness provable.
We turn short, self-contained papers in mathematics and theoretical computer science into Lean 4 proofs that a computer checks line by line. Human-led, AI-assisted, and delivered with a build you can rerun yourself.
Today: focused papers in mathematics and theoretical computer science. Next: algorithms, protocols and software.
$ lake build ✔ Build completed successfully. $ grep -rn "sorry" Paper/ | wc -l 0 #print axioms Paper.main_theorem 'Paper.main_theorem' depends on axioms: [propext, Classical.choice, Quot.sound] ∎ Lean's three standard axioms. Nothing else.
1,313theorems proved on prove2.me, each first to be solved
10,845theorem statements published to the prove2.me library
2graduate textbooks formalized, main results of every chapter
129,000lines in our Analytic Combinatorics library, on standard axioms only
What we do
⊢
Paper formalization
Your main theorems stated and proved in Lean 4 with Mathlib. Delivered as a buildable repository with a pinned toolchain, an axiom report, and notes on every place the formal proof differs from the paper.
≟
Statement review
A proof is only as good as its statement. We check by hand that each Lean statement says what the paper says: no missing hypotheses, no vacuous premises, no theorem that is true for the wrong reason.
λ
Refactoring & cleanup
Already have Lean code? We audit it, remove sorry and stray axioms, upgrade it to a current Mathlib, and restructure it so others can read and extend it.
Correctness proofs for algorithms and distributed protocols are available case by case. We have formalized population-protocol results, including the convergence-time bound for approximate majority (Angluin–Aspnes–Eisenstat, 2008).
Track record
Public, buildable, and open to inspection. Numbers below are those stated in each repository.
Analytic Combinatorics
Flajolet & SedgewickAll nine chapters of the standard reference, including the Hardy–Ramanujan asymptotic for the partition function proved without the circle method, singularity analysis, Lagrange inversion and Pólya theory.
- 419 Lean files
- ~129,000 lines
- 622 audited theorems
- standard axioms only
An Invitation to q-Series
Hei-Chi Chan, 2011The pentagonal number theorem, Jacobi triple product, Rogers–Ramanujan identities, Ramanujan's congruences modulo 5, 7 and 11, and a tenth-order mock theta identity. Every chapter's main result is checked by Lean.
- 258,052 lines
- 174 files
- ~27,600 theorems & lemmas
Silent self-stabilizing exact majority
SSS 2025Correctness and space optimality of the Kanaya et al. population protocol, with the impossibility result for protocols that do not know n. Zero sorry, standard axioms.
Fast robust approximate majority
Distrib. Comput. 2008A high-probability O(n log n) convergence-time bound for the three-state protocol of Angluin, Aspnes and Eisenstat.
Repository link available on requestStanley–Wilf growth limits
CombinatoricsThe unconditional growth-limit theorem for permutation classes, via Marcus–Tardos and the symbolic method, built on our analytic combinatorics library.
Repository link available on requestprove2.me
Open theorem libraryAs FormallyCorrect on the open Lean platform prove2.me, we have led nine formalization missions, published 10,845 theorem statements, and been first to prove 1,313 of them.
prove2.me →How a project runs
- 1
Send us the paper
Email the PDF (or arXiv link), the theorems you care about, and your deadline. Initial screening is free and takes about one business day.
- 2
Paid assessment
Within a fixed time box we read the proofs, map dependencies against Mathlib, and prototype the riskiest step. You receive a written report: proceed, major gap, refuted, or inconclusive.
- 3
Quote & statement of work
A written quote naming the exact theorems, the Lean and Mathlib versions, milestones, the acceptance test, and a cost ceiling. Nothing beyond it is billed without your approval.
- 4
Formalization
Work proceeds in milestones with status reports at agreed dates: on track, at risk, or blocked. No "90% done" progress bars.
- 5
Verified delivery
You see the build and the axiom report before final payment. After settlement we hand over the full repository.
- 6
Invoice & receipt
Formal invoices and paid receipts suitable for grant accounting and reimbursement.
What "verified" means
- It builds. A pinned
lean-toolchainandlake-manifest.json, solake buildreproduces our result on your machine. - No holes. Zero
sorry, zero custom axioms. We report the output of#print axiomsfor every headline theorem. - The right statement. Each formal statement is reviewed by a person against the paper, with differences written down.
- Readable. Organized by section of your paper, so a referee can find the proof of Lemma 3.2 without a guide.
When a paper has a gap
Formalization is unforgiving, and sometimes it finds real problems. We formalize; we do not rewrite your mathematics. If we hit a substantial error or gap, we stop, deliver a written report locating it as precisely as we can, and charge only for the work done under the agreed stage. Unused prepayment is refunded.
A proof we cannot formalize is not the same as a false theorem. We say which one we found, and we say what we did not check.
Pricing
Quoted by hand
Papers differ too much for a price list. A short combinatorics argument on well-supported Mathlib ground is a different job from a paper that needs new library infrastructure. Every project gets an individual quote after assessment, with a hard cost ceiling.
Pay in stages
The assessment is billed up front and credited toward the project if you go ahead. Larger projects are split into milestones, each paid on acceptance.
Institutional billing
Card and ACH through Stripe. Universities may pay by purchase order on Net 30 terms. A W-9 and formal invoice are available on request.
Your work stays yours
Files you send go to private, encrypted storage that only our team can open. We use them for your project and nothing else. We never publish your paper, code or results, and never show your project as an example, unless you say so in writing. When a project closes, we delete what you sent within 30 days, or right away if you ask.
We work with frontier AI models from Anthropic and OpenAI, with training on your material switched off, and a person directs every step. Correctness does not rest on any of them: every proof we deliver is checked by the Lean kernel, and every statement is read by a person. Working on something under embargo? Tell us. We are glad to sign an NDA and agree on how your material is handled.
Request a quote
We are a small, new practice. Every message is read and answered by a person, usually within a few hours.