Choose the proof assistant whose library already covers your domain, and only then negotiate about type theory. That is the conclusion the available evidence supports: in 2026, independent groups have shipped sorry-free formalizations of mathematical finance and elliptic PDE theory on top of Lean 4’s Mathlib, plus a quantum-information formalization of entropic inequalities on the same foundations, while every Arend claim cited here, including its library contents, comes from the developers’ own exposition paper. That asymmetry should drive the decision more than any feature checklist.
The occasion for revisiting the choice is real. On October 19, 2026, Arend’s developers published a fresh exposition of the prover on arXiv (arXiv:2610.27264, revised October 21), restating the case for a proof assistant built around univalent foundations. If you are starting a formalization project now, the honest framing is not “which tool is best” but “which burden do you want to carry”: Arend’s language ergonomics and univalent design, or Lean’s library gravity, or Coq’s long-established base. The sections below walk through each axis and end with a decision matrix.
Three foundations, one tradeoff
The three tools rest on genuinely different type theories, and the difference matters for what kinds of mathematics are native versus fought.
Arend is, per its developers, “designed to facilitate the formalization of mathematics within the framework of univalent foundations and with the focus on constructive mathematics.” Its underlying theory is a variant of homotopy type theory (HoTT) with cubical syntax that stays closer to Martin-Löf Type Theory than the fully computational cubical type theories, while keeping some useful computational behavior. In plain terms: equality in Arend behaves the way homotopy theorists want it to behave, by design rather than by axiom.
Lean 4 organizes mathematics through dependent types plus a heavy typeclass mechanism, and its library culture has optimized for classical mathematics with quotient types and choice: the finance and elliptic-PDE developments both pin their proofs to Lean’s three standard axioms, propext, Classical.choice, and Quot.sound. Per the instance-parameters study, “Like Coq, Lean is a dependently typed language based on the calculus of constructions.” That shared grounding matters for an important correction to the “univalent equals Arend” framing: univalent work is entirely possible in Coq. The UniMath bicategories paper mechanizes bicategory theory “in the UniMath library, which is based on the Coq proof assistant.” If your project needs univalent foundations, Arend is the tool designed around them, but Coq already hosts a working univalent library.
The tradeoff in one line: Arend makes univalent and constructive content native; Lean makes applied classical mathematics cheap through Mathlib; Coq hosts both classical developments and the univalent UniMath library.
What the Lean 4 and Mathlib stack demonstrably supports
The strongest evidence is not a feature list but finished work. Three independent 2026 formalization efforts, each a separate library built on top of Mathlib:
- A mathematical finance library in Lean 4 describes “more than three hundred sorry-free theorems across eleven areas,” built on Mathlib and the BrownianMotion package, including a construction of the L2 Itô integral and a derivation of the risk-neutral pricing measure rather than an assumption of it. Sorry-free means no admitted holes, though it says nothing about whether the development’s API is stable or its definitions complete.
- A formalization of linear elliptic PDE theory proves solvability of the Dirichlet problem for second-order linear elliptic operators in divergence form in Lean 4 on top of Mathlib, again with no sorry in the development.
- A quantum information formalization characterizes Mathlib as already containing “extensive formalized material in algebra, topology, measure theory, functional analysis, operator theory, C*-algebras, and continuous functional calculus.”
This is what library gravity looks like: when your project touches stochastic calculus, PDE analysis, operator theory, or measure-theoretic probability, a large fraction of the prerequisite formalization already exists and has been load-tested by people outside the core Mathlib team. The ecosystem tooling reinforces it. LeanExplore is a semantic search engine over Lean 4 declarations across indexed packages including Batteries, Init, Lean, Mathlib, PhysLean, and Std, which matters because in a library this size, finding the lemma is often the bottleneck, not proving it.
What arend-lib really contains
Against that, Arend’s library story is: “The main Arend library arend-lib includes formalizations in constructive algebra, topology and synthetic homotopy theory.” That sentence comes from the developers’ exposition, and it is the only inventory cited here; the abstract reports no size or completeness figures for arend-lib.
Read as the developers’ own positioning, the scope is coherent: constructive algebra, topology, and synthetic homotopy theory are exactly the domains where Arend’s univalent, constructive-by-design foundations pay off, and where porting to a classical system would be genuinely awkward. Synthetic homotopy theory in particular, where spaces are studied through HoTT’s primitive notions rather than through point-set topology, is a natural fit for Arend and an unnatural one for vanilla Lean.
But the asymmetry is the point. On the Lean side, independent teams chose Mathlib and shipped. On the Arend side, the evidence gathered here contains no third-party formalization built on arend-lib; until one appears, the library’s reach beyond its stated scope is an open question, not a known quantity.
Ergonomics under load: subtyping versus instances
The most interesting technical axis is how each system structures large hierarchies of mathematical definitions, because that is where formalization projects actually bleed time.
Arend’s headline mechanism is a class and record system with subsumptive subtyping: “Among the most notable features of the Arend language is its powerful system of classes and records supporting subsumptive subtyping, partial implementations and anonymous extensions, which provides extensive flexibility for constructing hierarchies of definitions.” Subsumptive subtyping means a richer structure can be used directly where a poorer one is expected: a ring is a group, no explicit coercion, no instance resolution step. For deep algebraic hierarchies, that removes a category of boilerplate entirely.
Lean’s answer to the same problem is typeclass instance parameters, and Lean’s own community has documented the cost. “As of February 2022, mathlib contains over 600 classes and over 8000 instances,” per the Use and abuse of instance parameters study, whose title flags that the mechanism is abused as well as used. The paper’s subject is what goes wrong as the hierarchy grows, and one documented performance trap is the unbundled-class style: “the linear growth in the types translates to an exponential growth in the term size of concrete instances.” Two cautions on the numbers: they date to February 2022 and, per the paper’s own abstract, describe the Lean 3 version of mathlib, so they understate the current Lean 4 library; and they count a mechanism’s scale, not its failure rate. Still, this is the rare case where the counter-evidence to a Lean-default recommendation comes from Lean’s own literature: the hierarchy boilerplate that Arend’s subtyping is designed to eliminate is real, measured, and named.
Subsumptive subtyping should reduce coercion boilerplate on paper; whether it does in a year-long project with five contributors is exactly the kind of thing only a pilot settles.
IDE and findability
Arend’s tooling pitch is unusually concrete for a research prover: “Formalization in Arend is streamlined by the IntelliJ Arend plugin, which transforms IntelliJ IDEA into a full-fledged integrated development environment (IDE) for the Arend language.” For teams already living in JetBrains tooling, a full-fledged IDE for the Arend language is a real adoption argument, and one you can check in an afternoon.
On the Lean side, the documented tooling advantage is findability: LeanExplore provides semantic search across the Lean 4 package universe. The two tools solve different problems. IntelliJ Arend optimizes the writing experience; LeanExplore optimizes the discovery problem inside a large library, which is the problem you actually have once a project grows.
Interop reality check
If your project might eventually need to exchange results with another assistant’s developments, the evidence is thin but not empty. A proof that Core Logic is not paraconsistent was certified in Coq “with no axiom assumed and every commitment displayed as a named hypothesis,” and “the same certification is replayed independently in Lean 4.” That establishes that a small, axiom-free proof can be ported across the Coq-Lean boundary by hand. It does not establish a migration pathway for libraries: one propositional-logic proof is a demonstration of logical compatibility, not of portability for the finance library’s 330-theorem development built on Mathlib’s class hierarchy.
For Arend, the exposition’s abstract describes no translation, proof export, or bridge to the Lean or Coq worlds. Choosing Arend means accepting ecosystem isolation as a working assumption: your formalization lives in Arend, and verification-by-replay elsewhere is unproven rather than merely untested.
Decision matrix by project type
| Project type | Recommended start | Evidence behind it | Main risk |
|---|---|---|---|
| Analysis-heavy (finance, PDEs, measure theory, operator algebras) | Lean 4 | Sorry-free finance and elliptic-PDE developments built on top of Mathlib; documented coverage through C*-algebras | Typeclass complexity on deep hierarchies |
| Synthetic homotopy theory, constructive algebra, univalent-native work | Arend | Designed for univalent foundations; arend-lib’s stated scope matches; subtyping cuts hierarchy boilerplate | Vendor-authored evidence only; ecosystem isolation |
| Univalent foundations with a long-established prover’s ecosystem | Coq with UniMath | Bicategory theory mechanized in UniMath on Coq | Coq’s library fit needs separate sizing |
| Logic certification with cross-checking ambitions | Coq, with Lean replay where feasible | One axiom-free Coq proof independently replayed in Lean 4 | Portability shown only for a single small proof |
| Hierarchy-heavy algebra where coercion boilerplate dominates the cost estimate | Pilot Arend against Lean 4 | Subsumptive subtyping (Arend) vs a documented 600-class, 8000-instance graph (Lean 3 mathlib, Feb 2022) | Ergonomic gain argued from design, not measured |
The porting row deserves emphasis: if your plan involves consuming or reproducing an existing Coq development, the independently replayed Core Logic proof is the only Coq-to-Lean replay in the evidence assembled here, and it is one small proof. If your plan involves Arend interop at all, treat it as an open research question and budget accordingly.
The verdict, and what to verify yourself
Default to Lean 4 when your domain overlaps what the Lean 4 and Mathlib stack demonstrably supports: sorry-free mathematical finance, elliptic PDE theory, and quantum information, each shipped in 2026 as a separate library built on top of Mathlib, plus the prerequisites Mathlib itself carries, from measure-theoretic probability to C*-algebras. Choose Arend when homotopy-type-theoretic or constructive content dominates the project, when the hierarchy ergonomics of subsumptive subtyping address a cost you can name, and when you can accept that the library, the IDE story, and the foundations all currently rest on the developers’ own account. Keep Coq in play for univalent work through UniMath, but size its library fit from other sources.
I would frame the pilot this way: take one representative theorem from your actual project, formalize its dependencies in both Lean 4 and Arend, and measure where the hours go. If the hours go to hunting and adapting existing Mathlib lemmas, library gravity has decided. If they go to fighting coercions and instance resolution in a deep hierarchy, Arend’s subtyping earns a serious look. What the evidence cited here cannot settle is everything that happens after month three: Arend’s adoption, performance, and library growth, and the current scale of Mathlib, whose February 2022 figures describe the Lean 3 library and are more than four years stale. The decision rule, library gravity before type theory, should survive those numbers changing; the specific verdict for your project deserves a week of your own testing before it deserves a commitment.
Frequently Asked Questions
What is the main recommendation for choosing a proof assistant?
Choose the proof assistant whose library already covers your domain, and only then negotiate about type theory.
What does the Arend library arend-lib contain?
The main Arend library arend-lib includes formalizations in constructive algebra, topology and synthetic homotopy theory.
Join the discussion
Share a useful perspective or ask a question about this article.