OpenProver: Agentic and Interactive Theorem Proving with Lean 4
Abstract: In this system paper, we present OpenProver, an open-source system for LLM-driven automated theorem proving (ATP) with integrated Lean 4 formal verification. OpenProver integrates a Planner-Worker-Verifier architecture inspired by recent ATP agentic systems such as Aletheia. A Planner agent maintains a compact Whiteboard scratchpad and an unbounded Repository of intermediate findings, and decomposes mathematical work into parallel Workers. OpenProver is fully open-source, offers reproducible evaluation through automatic formal verification of generated proofs, and provides an interactive terminal interface for human-guided proof search. In interactive mode, OpenProver allows the human operator to monitor and steer the proof search process, motivated by the established human-AI synergy in interactive code generation. To showcase the potential for quantitative ablation experiments enabled by automatic formal verification, we evaluate OpenProver on ProofNet and compare it with a simple baseline. OpenProver is publicly available at https://github.com/kripner/OpenProver.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What this paper is about
This paper introduces OpenProver, a free (openโsource) computer system that helps solve math problems by writing and checking proofs. It uses LLMsโthe kind of AI behind smart chat toolsโto suggest proof ideas, and it uses Lean 4, a strict math checker, to confirm if those proofs are correct. OpenProver can run by itself for fair, repeatable testing, or let a human guide it interactively like a coach working with a team.
2. What questions the paper tries to answer
In simple terms, the paper asks:
- How can we build a mathโproof system that is both powerful and trustworthy?
- Can we organize an AI โteamโ (with different roles) to explore proof ideas in parallel and make faster progress?
- Does plugging a strict proof checker (Lean) into the loop help us measure and improve results?
- How well does this team approach work compared to a simple, oneโtrack AI approach?
3. How OpenProver works (in everyday language)
Think of OpenProver as a small company trying to solve a math puzzle. It has three kinds of AI โpeople,โ each with a role:
- Planner: Like the team manager. It sets the plan, keeps notes, and decides what to try next.
- Workers: Like multiple teammates who try different ideas at the same timeโproving lemmas, checking special cases, hunting for counterexamples, or turning a rough proof into a formal one.
- Verifiers: Like careful editors or referees who independently review what each Worker produced to spot mistakes or missing steps.
To help the team remember and organize ideas, OpenProver uses two โmemoryโ tools:
- Whiteboard: A short, constantly updated summary of the current plan, failed attempts, and promising ideas. Think of it as the managerโs clean, readable notes.
- Repository: A tidy filing cabinet for longer piecesโdraft proofs, lemmas, or Lean code snippetsโsaved as small files and organized by labels.
What makes OpenProver trustworthy is its connection to Lean 4:
- Lean is like a superโstrict math teacher. It checks every proof step. If the proof doesnโt fully make sense, Lean says โno,โ and OpenProver goes back to fix it.
- OpenProver can also use tools to search Leanโs math library (Mathlib), verify small code snippets, and store useful building blocks as it goes.
Finally, thereโs an interactive mode:
- A human can watch what the Planner and Workers are doing, stop unhelpful directions, and nudge the planโlike steering a group project without doing all the work themselves.
A few technical terms explained simply:
- LLM: An AI that predicts the next words and can reason to some extentโlike a superโcharged autocomplete thatโs learned a lot of math text.
- ChainโofโThought: The AI โshows its workโ by writing down the steps itโs thinking through.
- Formal verification: Getting the strict checker (Lean) to confirm every step is logically validโno handโwaving allowed.
4. What the paper found and why it matters
The authors tested OpenProver on ProofNet, a collection of real math theorems used for benchmarking. They compared:
- A simple, straightโline approach (one conversation with the AI).
- OpenProverโs team approach (Planner + Workers + Verifiers + Lean checks).
With the same โword budgetโ per problem, OpenProver solved more problems across different underlying AI models. For example:
- Using the Kimi K2.5 model, success went from 36.8% (simple approach) to 57.3% (OpenProver).
- Using the Leanstral model, success went from 21.1% to 28.1%.
Why this is important:
- Better organization and independent checking lead to more correct proofs.
- Because Lean confirms correctness automatically, the results are reproducibleโother people can run the same setup and get the same pass/fail outcomes.
- The system can measure progress without human grading, which speeds up research and makes comparisons fair.
5. Why this work could matter in the future
OpenProver points toward math tools that are:
- Useful: A humanโAI partnership can explore more ideas faster and keep the good ones.
- Trustworthy: Formal checking with Lean catches errors that might be missed in casual writing.
- Measurable: Automatic verification makes it easy to run large experiments and compare methods.
- Evolving: Because much of the systemโs behavior is driven by prompts (instructions to the AI), OpenProver could improve itself over time by learning from what the checker accepts or rejects.
In short, OpenProver shows a practical way to combine creative AI with strict proof checking, helping both research and education move toward reliable, scalable, and interactive math problemโsolving.
Knowledge Gaps
Below is a focused, actionable list of the paperโs open questions, limitations, and knowledge gaps that future work could address.
- Evaluation scope: Results are only reported on a subset (185 items) of ProofNet; lack of clarity on subset selection criteria, difficulty strata, and coverage across mathematical domains.
- Metric definition: The paper does not specify whether โperformanceโ denotes Lean-verified proofs, natural-language proofs later formalized, or some mixed criterion; precise success metrics and pass@k definitions are missing.
- Statistical rigor: No confidence intervals, variance across seeds, or significance testing; robustness to decoding randomness (temperature, sampling) is unreported.
- Baselines: Comparison is only to a linear rollout; no head-to-head against contemporary agentic ATP systems (e.g., Aletheia, OpenGauss) or specialized Lean proof search baselines.
- Ablations: No component ablations to quantify contributions of Planner, Worker isolation, Verifier, Whiteboard, Repository, or Lean tool usage; unclear which elements drive gains.
- Token/cost efficiency: No analysis of wall-clock time, compute cost, token allocation per agent/tool, or throughput; scalability to larger budgets or lower budgets is untested.
- Scaling laws: Absent study of performance vs. number of Workers, Planner steps, token budget, or Verifier frequency; no guidance on hyperparameter tuning.
- Failure analysis: No qualitative or quantitative error taxonomy (e.g., flawed strategies, missing lemmas, formalization dead-ends, tool misuse) to guide targeted improvements.
- Formalization gap: The gap between finding an informal proof and producing a Lean proof is acknowledged but not quantified (e.g., success rate of formalization, average repair iterations, typical Lean errors).
- Autoformalization: The system assumes a Lean theorem file is available; ability to autoformalize raw natural-language statements (or translate across libraries) is not studied.
- Tool reliability: The effectiveness, precision/recall, and failure modes of
lean_search(LeanExplore) are not evaluated; impact of Mathlib versioning or missing lemmas is unmeasured. - Verifier efficacy: It is unclear how often the Verifier detects real flaws, reduces hallucinations, or improves final pass rate; no comparison to self-critique or alternative verification prompts.
- Worker isolation: While isolation reduces bias, it may cause redundant exploration; no mechanism or evaluation for deduplication, cross-pollination, or late-stage synthesis across Worker outputs.
- Memory management: The Whiteboard and Repository design lacks experiments on capacity limits, summarization quality, pruning heuristics, and retrieval effectiveness over long runs.
- Interaction benefits: The TUI is described but not evaluated; no user studies measuring speed-up, success rate, or cognitive load under Manual vs. Autonomous modes, or operator interventions that help most.
- Reproducibility: Prompts, decoding parameters, and exact tool configurations (e.g., Lean/Mathlib versions) are not fully specified; end-to-end scripts for deterministic re-runs are not described.
- Data contamination: Potential training data overlap with ProofNet (or Mathlib) is unaddressed; no controls to estimate leakage effects on reported gains.
- Generalization: No results on diverse benchmarks (e.g., miniF2F, Isabelle/HOL, Coq, HOL Light) or out-of-domain tasks; portability to other ITP ecosystems is untested.
- Curriculum/transfer: The system solves problems independently; no exploration of cross-problem memory, reusable lemma libraries, or curriculum strategies to accumulate formal knowledge.
- Robustness: Behavior under adversarial/ambiguous theorem statements, malformed Lean files, or degraded tool availability (offline
literature_search) is not characterized. - Internet tools:
literature_searchis not available in isolation mode; no controlled experiments quantify how internet access changes success rates, reliability, or reproducibility. - Proof quality: Beyond pass/fail, thereโs no assessment of proof readability, minimality, tactic quality, or reliance on brittle lemmas; no checks for degenerate or non-human-meaningful proofs.
- Safety/oversight: No discussion of safeguards against incorrect but Lean-accepted artifacts (e.g., using overly permissive axioms), or against unsafe automation in interactive settings.
- Self-improvement loop: The idea of using formal verification feedback for prompt/code evolution is proposed but not implemented or validated; no protocol, metrics, or stability analysis.
- Resource constraints: Requirements for GPUs/TPUs, parallelization limits, and scheduling of Planner/Workers/Verifiers at scale are unspecified; practicality for typical research labs is unclear.
- Open-source completeness: Repository availability is stated, but the paper does not confirm inclusion of all prompts, evaluation scripts, exact dataset splits, and environment lockfiles needed for full replication.
Practical Applications
Immediate Applications
The following applications can be deployed now using OpenProverโs open-source system, Lean 4 integration, PlannerโWorkerโVerifier architecture, Whiteboard/Repository memory, and interactive terminal UI.
- Reproducible benchmarking for LLM theorem provers (Academia; Software)
- What: Use OpenProverโs automatic Lean verification to run reproducible evaluations on datasets like ProofNet, compare agentic scaffolds, prompts, and models, and publish leaderboards with formally checked outcomes.
- Tools/workflows: CI pipelines that execute OpenProver in autonomous mode with fixed token budgets; experiment tracking (logs, Whiteboard snapshots, Repository items, DISCUSSION.md).
- Assumptions/dependencies: Availability of Lean 4 and Mathlib; access to reasoning LLMs (e.g., Kimi K2.5, Leanstral); compute budget.
- Human-in-the-loop proof search assistants for courses and research groups (Education; Academia)
- What: Run the interactive TUI in seminars, problem sessions, and research sprints so instructors/students can monitor agent output, veto unpromising Workers, and steer the Plannerโs next actions.
- Tools/products: โProof Studioโ workstation setup; classroom projector mode; LMS integration exporting proof artifacts and search histories for grading/feedback.
- Assumptions/dependencies: Instructor familiarity with Lean basics; institutional policies for LLM usage; student onboarding to Lean.
- Formal methods onboarding via Lean-scaffolded exercises (Education; Software)
- What: Assign students/engineers tasks where OpenProver generates an informal proof draft and iteratively formalizes it in Lean, teaching the gap between intuition and formalization.
- Tools/workflows: Template repositories with theorem skeletons (sorrys), guardrails requiring lean_verify to pass before submission.
- Assumptions/dependencies: Coverage of target topics in Mathlib; adequate compute for classroom scale.
- Mathlib contribution assistant (Open-source; Academia)
- What: Use Worker tasks plus lean_search (LeanExplore) to propose, verify, and store small lemmas or refactor proofs, with Verifier feedback to catch flaws.
- Tools/workflows: โProof PR botโ that runs OpenProver on new PRs or issues; Repository items mapped to PR comments with Lean-verified snippets.
- Assumptions/dependencies: Maintainer review; reliability of semantic search; consistent Lean 4 tooling.
- Team collaboration logs for proof sprints (Academia; Software)
- What: Leverage Whiteboard and Repository to maintain a compact, queryable scratchpad and a structured archive of partial results, failed avenues, and verified sublemmas.
- Tools/products: Export to wikis or knowledge bases; search over slugs and summaries to resume sessions.
- Assumptions/dependencies: Shared storage; version control hygiene.
- Agentic code-and-proof workflows for correctness-critical algorithms (Software; Finance)
- What: Treat algorithm specs as theorems and use Workers to generate proofs of properties (e.g., monotonicity, invariants) in Lean, producing artifacts that accompany releases.
- Tools/workflows: GitHub Action that runs OpenProver on specs each commit; โfail the buildโ on verification errors; informal-to-formal repair loops.
- Assumptions/dependencies: Specs formalizable in Lean; mapping between code-level properties and Lean statements; organizational buy-in.
- Prototype smart contract and crypto protocol reasoning (Finance)
- What: Formalize economic/security lemmas (e.g., no-arbitrage, collateralization bounds) in Lean and have OpenProver explore proof strategies with independent Workers.
- Tools/products: Audit support tool that bundles DISCUSSION.md and proof artifacts for external reviewers.
- Assumptions/dependencies: Domain libraries in Lean are limited; many protocols use other proof assistantsโinteroperability or re-encoding is needed.
- Automated regression checks for proofs in evolving repos (Software; Open-source)
- What: When library updates break proofs, use OpenProver to repair or refactor affected Lean Items, guided by verifier feedback.
- Tools/workflows: Pre-merge โproof repairโ bot that proposes Lean patches; tracked diffs in Repository items.
- Assumptions/dependencies: Non-trivial refactors may still require human expertise; LLM access.
- Prompt and policy ablations with verifiable outcomes (Academia; AI/ML)
- What: Run quantitative studies of agent designs (Planner prompting, number of Workers, independence constraints, Verifier prompts) with formal pass/fail signals.
- Tools/workflows: Automated grid searches over scaffolding parameters; dashboards showing success rates and token usage.
- Assumptions/dependencies: Compute cost; consistent datasets; statistical rigor.
- Math competition training with verifiable solutions (Education; Daily life)
- What: Use OpenProver to generate, decompose, and verify solutions to contest-level problems; learners can inspect failing attempts and successful strategies.
- Tools/products: Tutor mode in TUI; curated problem sets with Lean-checked solutions and annotated Whiteboards.
- Assumptions/dependencies: Not all contest tricks are in Mathlib; formalization gap for geometry and combinatorics patterns.
- โProof as an artifactโ for publications and preprints (Academia; Policy)
- What: Package OpenProver outputs (proof.lean plus search trace) as supplemental materials, improving reproducibility claims.
- Tools/workflows: Journal submission checklists that include Lean files; arXiv companion repos.
- Assumptions/dependencies: Community norms; reviewer familiarity with Lean.
- Training data generation for RL with verifiable rewards (AI/ML)
- What: Produce Lean-verified subproofs and failure traces to train/evaluate RLVR or reward models.
- Tools/workflows: Scheduled runs that mine new lemmas, label success/failure, and store them with metadata.
- Assumptions/dependencies: Data quality filters; deduplication; licenses and attribution.
Long-Term Applications
These opportunities likely require further research, domain libraries, scaling, or standardization before they are broadly feasible.
- Cross-domain formal verification of safety-critical systems (Healthcare; Robotics; Energy; Automotive; Aerospace)
- What: Prove properties of controllers, planners, and embedded algorithms (stability, safety invariants, collision avoidance, grid stability) with an agentic Lean workflow.
- Potential products: โSafety Proof Copilotโ integrated into ISO 26262/DO-178C pipelines; ROS/Autoware verification plug-ins.
- Assumptions/dependencies: Extensive domain-specific Lean libraries; traceable links from system requirements to Lean theorems; regulator acceptance of Lean artifacts; performance constraints for large-scale models.
- Certified analytics and decision pipelines (Healthcare; Finance; Public policy)
- What: End-to-end verification of statistical models, causal assumptions, and optimization routines underlying clinical decisions, risk scoring, or policy simulators.
- Potential products: Audit-ready โDecision Justification Dossiersโ with formal proofs, counterexample analyses, and Planner/Verifier traces.
- Assumptions/dependencies: Formal encodings of statistical theory, probability, and optimization primitives in Lean; institutional standards for accepting formal proofs as evidence.
- Autonomous mathematical research agents (Academia)
- What: Systems that propose conjectures, plan proof programs, search literature, and generate Lean-certified proofs at or beyond graduate level.
- Potential products: โLab-in-the-loopโ platforms where agents run 24/7 and surface promising lemmas and roadmaps to human collaborators.
- Assumptions/dependencies: Stronger reasoning models; richer math libraries; robust literature-grounded tool use; safeguards against spurious formalizations.
- Verified software and hardware synthesis loops (Software; Semiconductors)
- What: Synthesis of code or circuits with embedded specifications that are simultaneously proven in Lean, closing the loop between design, implementation, and proof.
- Potential products: IDEs that co-generate code and Lean proofs; โProof-first CI/CDโ for kernels, compilers, and accelerators.
- Assumptions/dependencies: Bridges from Lean to program logics/spec languages; scaling verification to industrial codebases; performance and maintainability.
- Regulation-ready proof standards for AI systems (Policy; AI governance)
- What: Require agentic AI components to output verifiable artifacts (e.g., Lean proofs of safety properties, bounded error guarantees) for certification.
- Potential products: Compliance toolkits bundling OpenProver with document generation for audits and conformity assessments.
- Assumptions/dependencies: Standardization bodies endorsing Lean-style proofs; legal frameworks; third-party verification services.
- Self-improving agents via verifiable feedback loops (AI/ML)
- What: Use Lean pass/fail signals to automatically optimize prompts, heuristics, and tool choices (e.g., Feedback Descent, AlphaEvolve) for theorem proving and beyond.
- Potential products: Auto-tuning โscaffolding optimizersโ that learn Planner/Worker/Verifier policies over time.
- Assumptions/dependencies: Stable training signals; prevention of reward hacking; compute budgets for iterative improvement.
- Multimodal scientific discovery with formal guarantees (Science; Engineering)
- What: Extend PlannerโWorkerโVerifier to physics/chemistry/control models, producing Lean-backed claims about models, invariants, and simulations.
- Potential products: โFormal Lab Notebooksโ where hypotheses, derivations, and validation steps are machine-checked.
- Assumptions/dependencies: Formalization of relevant scientific domains; tooling to connect numerical solvers with symbolic proofs; community adoption.
- Verified educational content generation at scale (Education; Publishing)
- What: Automatically produce curricula, problem sets, and solution manuals with Lean-certified correctness and pedagogical scaffolding.
- Potential products: Adaptive platforms that select problems and proofs based on learner progress, with guaranteed correctness.
- Assumptions/dependencies: Coverage of Kโ12 and undergraduate domains in Lean; content alignment with standards; UX for non-experts.
- Proof-guided agent frameworks beyond math (Software; Operations)
- What: Generalize PlannerโWorkerโVerifier and Whiteboard/Repository to complex workflows (e.g., incident response, cloud configuration) where constraints can be formalized.
- Potential products: โOperational Proversโ that certify runbooks meet policy constraints before execution.
- Assumptions/dependencies: Suitable formal logics/specifications for target workflows; integrations with operational tooling.
- Marketplace and cloud services for โProof as a Serviceโ (Software; Finance; Healthcare)
- What: On-demand agents that take a specification and return Lean proofs and search traces, with SLAs for turnaround and verification.
- Potential products: APIs, usage-based billing, private deployments for sensitive IP.
- Assumptions/dependencies: Data privacy and security; model hosting; interoperability with client toolchains; pricing sustainability.
- Interoperability across proof assistants and languages (Software; Formal methods)
- What: Translate OpenProver outputs between Lean, Coq, Isabelle, and domain-specific verification tools to meet organizational and regulatory preferences.
- Potential products: โProof Bridgeโ services that port artifacts while preserving guarantees.
- Assumptions/dependencies: Reliable translation layers; aligned libraries; possible semantic gaps between systems.
- Real-time proof-aided control and monitoring (Robotics; Energy)
- What: Agents that propose control updates accompanied by fast-checkable proofs of constraint satisfaction in dynamic environments.
- Potential products: Supervisory controllers with on-the-fly verification of safety envelopes.
- Assumptions/dependencies: Ultra-fast verification pipelines; incremental proofs; specialized libraries for control theory and dynamics in Lean.
Notes on general dependencies across applications:
- Strength and availability of reasoning LLMs, token budgets, and compute cost.
- Maturity and coverage of Lean 4 and Mathlib in targeted domains.
- Organizational readiness to adopt formal artifacts in development and compliance.
- Data governance, IP, and privacy concerns when using cloud models.
- Usability and training for practitioners unfamiliar with formal methods.
Glossary
- Ablation experiments: controlled studies that remove or vary components to assess their impact on performance. "quantitative ablation experiments"
- Agentic scaffolding: a system design that wraps an LLM in structured roles, tools, and loops so it can act as an autonomous agent. "executed in an agentic scaffolding"
- Aletheia: a fully autonomous LLM-driven automated theorem proving system referenced as prior work. "An example of such a system is Aletheia [3]."
- Automated Theorem Proving (ATP): the use of algorithms and systems to automatically generate mathematical proofs. "Automated Theorem Proving (ATP) has seen a significant rise in capabilities"
- Chain-of-Thought (CoT): an LLM prompting technique that elicits step-by-step reasoning traces. "Produce reasoning trace (CoT);"
- Formal ATP: the branch of ATP that works with fully formalized proofs in a proof assistant rather than informal text. "An essential limitation of formal ATP is the fact that formalization is often more challenging than the informal proof search."
- Formal theorem statement: a machine-checkable encoding of a theorem in a proof assistantโs language. "the formal theorem statement is provided on input"
- Formal verification: machine-checking a proof for correctness using a proof assistant. "integrated Lean 4 formal verification."
- Formalization: the process of translating informal mathematics into the strict syntax and semantics of a proof assistant. "formalization is often more challenging than the informal proof search."
- Interactive Theorem Provers (ITPs): systems that allow human users to guide or interact with the proof process. "interactive theorem provers (ITPs) enable the user to monitor and intervene in the proof search process"
- Kimi K2.5: a reasoning-capable LLM used as one of the underlying models in experiments. "Kimi K2.5 [4]"
- Lean 4: a modern interactive theorem prover and programming language used for formal verification. "Lean 4 formal verifier"
- LeanExplore: a search tool for Lean that retrieves relevant definitions and lemmas. "LeanEx- plore [1]"
- Leanstral: an open-source model used as a reasoning backbone for experiments. "Leanstral [7]"
- Mathlib: the community-driven mathematical library for Lean containing definitions and theorems. "Mathlib [11]"
- Model-agnostic: not tied to a specific model; able to work with multiple LLM backends. "OpenProver is model-agnostic and can utilize any reasoning model"
- Planner-Worker-Verifier architecture: a multi-agent design where a planner coordinates workers and independent verifiers. "Planner- Worker-Verifier architecture"
- ProofNet: a benchmark of undergraduate-level mathematics for autoformalization and formal proving. "evaluate OpenProver on ProofNet"
- Reasoning Cache: a technique to extend effective context or reuse reasoning across steps for long-horizon tasks. "Reasoning Cache [14]"
- Reinforcement Learning from Verifiable Rewards (RLVR): training LLMs using reward signals derived from verifiable outcomes like proof checks. "Reinforce- ment Learning from Verifiable Rewards (RLVR) [13]"
- Semantic search: retrieval based on meaning (embeddings) rather than exact keyword matching. "Perform semantic search over Mathlib [11]"
- Sorry keyword: a Lean placeholder that marks a missing proof, allowing incomplete developments to typecheck. "with one or more sorry keywords."
- Terminal User Interface (TUI): a text-based interface for interacting with the system in a terminal. "interactive Terminal User Interface (TUI)"
- Tool Calls: LLM-invoked external functions or tools used to perform tasks such as verification or search. "Tool Calls [10]"
- Token budget: a cap on the number of tokens (compute/IO units) allocated for solving a problem. "under the same token budget"
- Verifier (agent): an independent agent that checks worker outputs and provides critical feedback. "Verifiers: Independently verify each Worker output, providing additional context to the Planner."