OProofs in Lean-4 Theorem Proving

• OProofs is a Lean-4 corpus that combines formal statements, compiler-verified proofs, and agentic proving trajectories into a unified training resource.
• It supports iterative model training through next-token modeling, supervised repair examples, and reinforcement learning on hard cases.
• The corpus scales with over 1.7M unique statements and 6.8M proofs, enabling robust retrieval and refinement in automated theorem proving.

OProofs, in the Lean-4 theorem-proving literature, denotes the training corpus behind OProver, a unified framework for agentic formal theorem proving. In that setting, OProofs is a dataset of formal statements, compiler-verified proofs, and serialized agentic proving trajectories, and it underpins continued pretraining, supervised fine-tuning, and reinforcement learning. The current Lean-4 snapshot contains 1 770 000 unique Lean statements, 6 860 000 compiler-verified proofs, and 1 070 000 serialized agentic proving trajectories; across five benchmarks, OProver-32B attains the best Pass@32 on MiniF2F (93.3%), ProverBench (58.2%), and PutnamBench (11.3%), and ranks second on MathOlympiad (22.8%) and ProofNet (33.2%), with more top placements than any prior open-weight whole-proof prover (Ma et al., 17 May 2026). In other research contexts, the same label has also been used for OR-aggregated Merkle inclusion proofs and, in singular form, for proof objects in proof-structure analysis.

1. Formal definition and training role

Formally, OProofs is viewed as a set

$D = \{ (s, P_s, T_s) \},$

where for each formal statement $s$, $P_s = \{p^{(1)}, p^{(2)}, \dots\}$ is the set of compiler-verified proofs of $s$, and $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$ is the set of serialized agentic proving trajectories for $s$. Each trajectory $\tau$ is a sequence of rounds $t = 1 \dots T$ recording $(R_t, p_{t-1}, f_{t-1}, p_t)$, where $R_t$ is the retrieved proof context at round $s$0, $s$1 is the previous proof attempt, $s$2 is the Lean compiler feedback on $s$3, and $s$4 is the revised proof attempt (Ma et al., 17 May 2026).

This formalization makes OProofs more than a repository of end-state proofs. During continued pretraining, raw statements and final proofs in OProofs are used as next-token modeling data. During supervised fine-tuning, the round-level pairs $s$5 are used to teach the model how to repair. During reinforcement learning, OProofs seeds the retrieval memory and supplies hard cases, namely unresolved statements, for policy optimization. The corpus therefore encodes both proof products and proof dynamics: retrieval-grounded attempts, Lean feedback, and local repair transitions (Ma et al., 17 May 2026).

A central implication of this design is that agentic proving is not deferred to inference time. Instead, failed proof attempts, compiler diagnostics, and subsequent revisions are directly embedded in the training signal. This suggests a shift from training purely on successful proofs toward training on the operational process by which proofs are recovered after failure.

2. Scale and corpus composition

The current Lean-4 component of OProofs has the following reported statistics (Ma et al., 17 May 2026).

Component	Quantity	Detail
Unique Lean statements	1 770 000	Lean-4 statements
Compiler-verified proofs	6 860 000	4 330 000 carry retrieved context
Proofs obtained after non-trivial compiler feedback	869 000	Subset of verified proofs
Serialized agentic proving trajectories	1 070 000	164 000 involve at least one repair
Round-level repair examples	280 000	Extracted from repair trajectories
Continued-pretraining tokens	51.8 billion	Lean tokens using the Qwen3 tokenizer

Two features of these statistics are structurally important. First, OProofs is highly multi-proof: a single statement may admit multiple compiler-verified proofs, which is consistent with the formal definition of $s$6 as a possibly multi-element set. Second, the trajectory component is not marginal. Of the 1 070 000 serialized trajectories, 164 000 involve at least one repair, and these yield 280 000 round-level repair examples. In effect, the corpus provides both theorem–proof supervision and localized edit supervision conditioned on retrieval and Lean feedback (Ma et al., 17 May 2026).

The token count further indicates that OProofs is used at pretraining scale rather than merely as a fine-tuning collection. The 51.8 billion Lean tokens are formed from statements plus proof text, so the corpus spans theorem signatures, proof scripts, and the linguistic regularities of Lean-4 formalization.

3. Data sources and construction pipeline

OProofs is built in two main branches. The first branch starts from public Lean resources. Open-source Lean-4 statements are collected from repositories such as NuminaMath-LEAN, Lean-Workbook, Leanabell-FormalStmt, and Goedel-Pset; the statements are deduplicated by exact and near-duplicate matching of theorem signatures; a baseline agentic prover, using open-source models, is then run on every unique statement, and only compiler-verified proofs are retained (Ma et al., 17 May 2026).

The second branch begins with raw informal sources. Common Crawl and GitHub are scraped for web pages classified by a FastText model as “mathematical.” The informal statements are filtered and autoformalized into Lean-4 syntax using Criticlean. Agentic proving is again run, and only Lean-verified proofs are kept (Ma et al., 17 May 2026).

A third, ongoing mechanism is continuous corpus growth through model improvement. As OProver itself improves, newly verified proofs and repair traces are continuously appended to OProofs, so the corpus co-evolves with the model. This co-evolution is a defining property of the dataset: OProofs is not fixed once collected, but expands through the proving behavior of the system it trains (Ma et al., 17 May 2026).

The pipeline therefore combines public formal corpora, autoformalized informal mathematics, and agentic traces generated by the prover. This suggests that OProofs functions simultaneously as a harvested corpus, a synthesized corpus, and a self-expanding training memory.

4. Record schema, serialization, and retrieval memory

Every record in OProofs is one of two high-level types. The first is a statement–proof pair with fields for the Lean-4 theorem signature and type, the final compiler-verified proof script, a source label drawn from "public" | "autoformalized" | "agentic-round-K", and metadata including domain, difficulty, repository, and commit hash. The second is an agentic proving trajectory with a statement, a list of rounds, a final status in "verified" | "timeout" | "unsolved", and a total round count $s$7 (Ma et al., 17 May 2026).

Within each round of a trajectory, the stored fields are retrieved_context, previous_attempt, feedback, and revised_attempt. All records are stored as one JSON object per line in JSON L. Proof scripts and error messages are kept as raw UTF-8 strings, with no further tokenization or taxonomic encoding (Ma et al., 17 May 2026).

Retrieval is organized around a memory $s$8 that is simply the index of all $s$9 pairs in OProofs. A sentence-embedding model $P_s = \{p^{(1)}, p^{(2)}, \dots\}$0—Qwen3-8B-Embedding—is trained on known theorem–proof pairs to embed statements into a high-dimensional vector. Given a target statement $P_s = \{p^{(1)}, p^{(2)}, \dots\}$1, the system retrieves the top $P_s = \{p^{(1)}, p^{(2)}, \dots\}$2 proofs by cosine similarity,

$P_s = \{p^{(1)}, p^{(2)}, \dots\}$3

These $P_s = \{p^{(1)}, p^{(2)}, \dots\}$4 retrieved proofs are concatenated into the prompt at each round, and the index is updated after each post-training iteration by re-embedding newly verified proofs (Ma et al., 17 May 2026).

The trajectory schema makes explicit that repair is retrieval-conditioned and feedback-conditioned. A typical example is a two-round trajectory for the lemma nat.add_comm, in which an initial by sorry attempt produces compiler feedback such as error: expected element of type Nat, got Prop, followed by a revised attempt based on induction; a later round records no goals remaining, and the final status is "verified" (Ma et al., 17 May 2026).

5. Integration into iterative post-training

Algorithm 1 of the OProver paper describes an iterative loop in which OProofs and the model are updated together. The process begins with OProver-Base after continued pretraining and an initial corpus $P_s = \{p^{(1)}, p^{(2)}, \dots\}$5, which is indexed to form $P_s = \{p^{(1)}, p^{(2)}, \dots\}$6. For $P_s = \{p^{(1)}, p^{(2)}, \dots\}$7, the system runs multi-round agentic proving on a pool $P_s = \{p^{(1)}, p^{(2)}, \dots\}$8 of target theorems, retrieving from $P_s = \{p^{(1)}, p^{(2)}, \dots\}$9 and verifying with Lean; collects newly verified proofs $s$0 and appends them to $s$1; extracts round-level repair examples

$s$2

identifies hard cases $s$3, defined as statements with partial but not full success among sampled rollouts; re-indexes $s$4; and updates the policy $s$5 by first fine-tuning on $s$6 and then reinforcement learning on $s$7 using GSPO (Ma et al., 17 May 2026).

Two effects are stated explicitly. Each time new proofs and trajectories are added to OProofs, both the supervised and RL stages see richer examples of retrieval-grounded, feedback-conditioned repair. Over iterations, this co-evolution drives larger coverage of solvable statements and higher proof success rates (Ma et al., 17 May 2026).

The benchmark results reported for OProver-32B give empirical context for the corpus design. Best Pass@32 is achieved on MiniF2F, ProverBench, and PutnamBench, while second place is reported on MathOlympiad and ProofNet. A plausible implication is that the value of OProofs lies not only in corpus size but in the combination of verified endpoints, retrieval memory, and serialized repair trajectories.

6. Other uses of the name

In a separate zero-knowledge setting, “OProofs” has been used for Merkle-tree inclusion proofs built by OR aggregation. There, if $s$8 are zero-knowledge proofs of individual statements “leaf $s$9 is in the Merkle tree,” with verification predicate $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$0, the OR-aggregate is a single proof $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$1 satisfying

$T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$2

The resulting universal proof is constant size, verification can be performed using any single valid leaf hash, and the complexity analysis states $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$3 proof size, $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$4 communication, and $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$5 verification time, in contrast to linear behavior for traditional AND aggregation. The same source also describes hybrid AND/OR constructions for more expressive acceptance functions, including access policies, multi-party signatures, conditional transfers in smart contracts, and threshold-voting schemes (Kuznetsov et al., 2024).

In proof-structure analysis, the singular term “OProof” denotes a proof represented as a pair consisting of a term $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$6 built over a binary constructor $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$7 and an axiom assignment $T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$8, formally

$T_s = \{\tau^{(1)}, \tau^{(2)}, \dots\}$9

This formalism is restricted to first-order problems characterized by condensed detachment and is used for global manipulation and analysis of proofs as objects. Reported experiments on Łukasiewicz’s problem include Meredith’s 33-step variation with compacted size 32, tree size 491, and height 29; the original Łukasiewicz proof converted to condensed detachment with compacted size 34, tree size $s$0, and height 29; and a new short proof discovered by PSP-enumeration with compacted size 22, tree size 64, and height 22. Search times are reported as $s$1 min for the OTTER/Prover9 baseline and $s$2 s for SGCD$s$3 (Wernhard et al., 2023).

These usages are conceptually distinct. The Lean-4 OProofs corpus is a training and retrieval substrate for agentic theorem proving; the OR-aggregation OProofs are universal zero-knowledge inclusion proofs; and the proof-structure OProof is an abstract representation for analyzing derivations under condensed detachment. The shared label reflects an emphasis on proofs as structured computational objects, but not a single unified formalism.