---
title: 'DreamProver: Adaptive Theorem Proving Framework'
url: https://www.emergentmind.com/topics/dreamprover
type: topic
---

# DreamProver: Adaptive Theorem Proving Framework

Searching arXiv for DreamProver and closely related theorem-proving work.
arXivSearch(query="DreamProver theorem proving wake sleep lemma library", max_results=10)
arXivSearch(query="2604.26311", max_results=5)
DreamProver is an agentic formal-theorem-proving framework that learns a reusable lemma library through a wake–sleep program-induction loop. Instantiated in Lean 4, it addresses a central limitation of many LLM-based provers: they either depend on fixed libraries or generate auxiliary lemmas that are highly specific to individual theorems and therefore exhibit little reuse. DreamProver alternates between a wake stage, in which it attempts proofs and harvests intermediate theorems, and a sleep stage, in which it abstracts, validates, deduplicates, and prunes candidate lemmas. The resulting library is intended to remain compact while becoming progressively more transferable across unseen theorems within a domain [2604.26311].

## 1. Problem setting and conceptual objective

DreamProver operates in standard formal theorem proving over Lean 4 propositions and proofs. A theorem is a Lean proposition with a name and type; a proof is a Lean term inhabiting that type; and a lemma is simply a theorem intended for reuse. The persistent object learned by the system is a domain-specific lemma library \(L\), a finite set of formally proved lemmas that is learned from a training set \( \mathcal{T}_{\text{train}} \) and then frozen for evaluation on \( \mathcal{T}_{\text{test}} \) [2604.26311].

The framework is motivated by the observation that human mathematicians do not solve each theorem in isolation. Instead, they accumulate reusable abstractions. DreamProver attempts to reproduce that behavior operationally: it does not merely search for proofs, but also reorganizes proof experience into a compact stock of high-level lemmas. In the reported experiments, a lemma is treated as “transferable” in an operational sense if it is learned from training theorems and then appears in proofs of multiple distinct test theorems; empirically, about **58%** of learned lemmas are reused on test theorems, and they contribute to proofs of **71%** of solved test theorems [2604.26311].

This design places DreamProver between two familiar regimes. It is more adaptive than fixed-library systems, because the library is explicitly evolved for the target domain. It is also more persistent than per-theorem decomposition systems, because intermediate results are not discarded after a single proof attempt; they are abstracted and retained if they survive later validation and compression. A plausible implication is that DreamProver treats theorem proving as a cumulative knowledge-organization problem as much as a search problem.

## 2. Wake stage: proving, decomposition, and intermediate theorem discovery

In the wake stage, DreamProver tries to prove each training theorem using the current library \(L\). The first mode is direct proving: for each theorem \(x \in \mathcal{T}_{\text{train}} \), the system prompts an LLM with the Lean theorem statement, the current library, and instructions such as no imports and no `sorry`. The compute budget is fixed at a maximum of **4** direct proof attempts and **6** error-correction iterations per attempt. If a valid Lean proof is found, the theorem is marked as learnable and added to the pool later used for abstraction [2604.26311].

If direct proving fails, DreamProver invokes recursive theorem decomposition. The LLM is first asked for an informal proof sketch and then for a Lean proof sketch whose main structure is explicit `have` subgoals, each ending in `by sorry`, while the top-level theorem is proved from those subgoals. The prompt constrains each `have` to be logically simpler than the original theorem, forbids nested `have`s, and requires explicit naming. A second prompt then extracts each `have ... := by sorry` into a separate theorem of the form `theorem subgoal_name ... : ... := by sorry`, thereby producing intermediate theorems that can later seed library growth [2604.26311].

DreamProver does not treat every decomposition as valid merely because it is syntactically produced. It attempts to reassemble the original proof by treating the extracted subgoals as assumed lemmas and checking whether the main theorem can be proved from them, both syntactically and through Lean type checking. It also uses an LLM-based natural-language sanity check to discard obviously inconsistent decompositions. Early in training, when the library is nearly empty, more than one decomposition level is often required; as the library matures, more theorems become directly provable or solvable after only one decomposition [2604.26311].

At training time, the maximum decomposition depth is **3**; at test time, it is reduced to **1**. This suggests that DreamProver uses deeper decomposition primarily as a knowledge-acquisition mechanism during library formation, while keeping inference-time behavior relatively shallow and library-centric.

## 3. Sleep stage: abstraction, clustering, and library evolution

The sleep stage is the mechanism by which proof experience is compressed into reusable abstractions. DreamProver begins by taking the accumulated pool of learnable theorems and intermediate theorems from the wake stage and producing a short natural-language annotation for each one. The annotation records the sub-domain, an approximate difficulty level, and relevant known lemmas or theorems that might prove it. These descriptions are then embedded with **Sentence-MPNet**, distances are computed by cosine distance, and **K-means** is applied with the number of clusters \(K\) chosen by the **elbow method** [2604.26311].

For each cluster, the LLM receives both the full Lean statements and the corresponding natural-language descriptions and is asked to propose one or more new, more general lemmas for the domain. The prompt requires Lean theorem statements only, without proofs, no imports, and variable/type patterns aligned with the cluster rather than excessive polymorphism. The intent is not to restate cluster members verbatim, but to synthesize a more abstract statement capable of serving as a reusable premise across related problems [2604.26311].

Candidate lemmas are then filtered structurally. DreamProver parses both a candidate lemma and each theorem in the cluster into simplified first-order-logic expression trees and computes a structural similarity score based on tree alignment. If the maximum similarity to the cluster exceeds a threshold, the candidate is retained; otherwise it is discarded as not genuinely representative of the cluster. Near-duplicates against the existing library are removed using **tree edit distance**. This gives the system two distinct structural controls: one for cluster coverage and one for redundancy [2604.26311].

Library maintenance is explicitly capacity-constrained. The library is kept below **100 lemmas**, and if adding new lemmas would exceed capacity, DreamProver evicts entries using a **least-recently-used** criterion defined by recent usage during wake-stage proving. Surviving candidates are then formally proved in Lean using the same LLM-based direct prompting protocol, and only verified lemmas are inserted into \(L\). The library therefore stores theorem statements whose proofs are known to exist in the environment, not unverified hypotheses [2604.26311].

## 4. Lemma representation, inference-time proving, and learned content

DreamProver integrates at the LLM level rather than by modifying Lean’s kernel, and it does not introduce additional task-specific neural networks beyond off-the-shelf LLMs plus the sentence-embedding model used for clustering. Its proof search at inference time is two-tiered. First, it attempts whole-proof generation with the learned library in context. If that fails, it falls back to sketch-and-prove: generate a proof sketch with subgoals, extract the subgoals into separate theorems, prove those subgoals with the same library in context, and then assemble the final proof [2604.26311].

The learned library consists of ordinary Lean 4 theorem statements rather than proof scripts. Representative examples reported for the inequality domain include lemmas corresponding to **AM–GM**, **AM–HM**, **Cauchy–Schwarz**, **Titu’s lemma**, **Schur’s inequality**, **Hölder’s inequality**, **Nesbitt’s inequality**, **weighted AM–GM**, **Newton’s inequality**, and the **rearrangement inequality**. In number theory, the library includes statements such as `dirichlet_theorem_on_arithmetic_progressions` and `coprime_iff_forall_prime_not_dvd`. In combinatorics, it includes lemmas such as `choose_symm_comb` and `Finset.card_eq_of_mem_powersetCard`. In plane geometry, the learned content covers power-of-a-point and center-related facts, while in machine learning theory it covers strong-convexity and Lipschitz-gradient inequalities as well as quadratic-form identities [2604.26311].

The following implementation details summarize the main cycle:

| Component | Setting |
|---|---|
| Wake–sleep cycles | 5 per domain |
| Direct proof attempts | 4 |
| Error-correction iterations | 6 per attempt |
| Max decomposition depth | 3 during training; 1 during inference |
| Library capacity | \< 100 lemmas |

The reported behavior indicates that the library is not merely decorative context. In the inequality domain, for example, learned lemmas were used to shorten proofs by turning difficult rational or symmetric inequalities into one-step applications of higher-level results such as `titu_lemma_three_reals`. A common misconception is that DreamProver simply accumulates many low-level decompositions and retrieves them. The ablations indicate the opposite: iterative abstraction and compression into a small, high-level library are materially more effective than maintaining a large, noisy pool [2604.26311].

## 5. Empirical performance, efficiency, and ablations

DreamProver is evaluated across five domains: inequalities, number theory, combinatorics, plane geometry, and machine-learning theory. For the well-represented domains, the training set contains **100 problems** per domain; for plane geometry, the library is learned from the IMO subset of LeanGeo-Bench; and for machine-learning theory, it is learned on the level-2 subset of FormalML and evaluated on the harder level-3 subset containing **122** problems. Baselines include proprietary reasoning LLMs, open-source prover LLMs such as DeepSeek-Prover-V2 and Goedel-Prover-V2, and the recursive agentic system Hilbert [2604.26311].

The main quantitative findings are strong both in accuracy and in efficiency. Averaged across well-represented domains and backbones, DreamProver achieves about **61% relative improvement** over Hilbert. With a Gemini 3.1 Pro backbone, it solves **57/92 (62.0%)** on 567NEQ, **36/42 (85.7%)** on ChenNEQ, **17/20 (85.0%)** on MO-INT, **19/66 (28.8%)** on PutnamBench, **25/40 (62.5%)** on ProverBench, and **27/43 (62.8%)** on CombiBench. In under-represented domains, it solves **17/20** synthetic geometry problems, **9/10** high-school competition geometry problems, **7/19** Olympiad geometry problems, and **93/122 (76.2%)** on FormalML-Hard, where the strongest standalone LLM baselines are much lower [2604.26311].

| Benchmark | DreamProver result | Comparator |
|---|---|---|
| 567NEQ | 57/92 (62.0%) | Hilbert 51/92; GPT-5.3 44/92 |
| PutnamBench | 19/66 (28.8%) | Best baseline 8/66 |
| FormalML-Hard | 93/122 (76.2%) | GPT-5.3 59/122 |

Efficiency gains are equally central. Relative to Goedel-Prover-V2-32B, DreamProver reduces output token usage by **55%**, **56%**, and **76%** on inequalities, number theory, and combinatorics, respectively; relative to Hilbert with the same backbone, the reductions are **42%**, **50%**, and **53%**. Averaged over the well-represented domains, the savings are about **62%** versus the open-source prover and **48%** versus Hilbert. Proofs are also shorter: DreamProver cuts proof length by about **32%** relative to Goedel-Prover-V2 and **50%** relative to Hilbert on average across those domains [2604.26311].

The ablations isolate what the system is actually gaining from lemma evolution. On the combined inequality benchmarks, full DreamProver solves **104** problems. Removing library optimization drops this to **76**. Removing cluster-based evolution as well drops it further to **53**, which is worse than the **55** solved by the no-library baseline. A single-pass library plus semantic retrieval solves **61**. These results support a specific interpretation: the improvement does not come from merely adding more premises, but from iterative abstraction, pruning, and consolidation into a compact library of reusable high-level lemmas [2604.26311].

## 6. Position in the literature, misconceptions, and limitations

DreamProver is explicitly situated against three neighboring paradigms. Relative to fixed-library proving, it learns domain-adapted premises rather than assuming the relevant abstractions are already present. Relative to per-theorem lemma synthesis, it persists lemmas across problems and demands later reuse. Relative to prior library-learning systems such as LEGO-Prover, it reports substantial rather than negligible test-time reuse. A related but distinct direction is 3D-Prover, which augments an underlying tactic generator by learning semantically aware tactic representations and using Determinantal Point Processes to select semantically diverse, high-quality tactics at each proof-search node [2410.11133]. DreamProver, by contrast, optimizes a persistent cross-theorem resource—the lemma library—rather than a per-node tactic subset [2604.26311].

The name can also be misleading outside theorem proving. Despite the shared “dream” vocabulary, DreamProver is not a Dreamer-style model-based RL system using active latent intervention on latent manifolds [2605.16030], nor is it a language-model feature-visualization method that optimizes prompts for internal activation under a fluency objective [2402.01702]. Its “wake–sleep” terminology refers instead to a program-induction cycle in which proof attempts generate structured experiences and a later compression phase reorganizes them into reusable symbolic knowledge [2604.26311].

Several limitations are explicit. The library is kept small enough to fit within current context windows, but scaling to smaller models or to unknown domains with multiple libraries may require explicit premise selection. The method assumes a reasonably sized training set in the target domain; for sparse or research-level areas, online continual lemma learning would likely be necessary. The wake–sleep process is heuristic and provides no guarantee that the resulting library is minimal or globally optimal. Finally, abstraction quality depends heavily on the LLM’s ability to propose genuinely good general lemmas and on relatively simple structural similarity metrics rather than stronger anti-unification or symbolic synthesis procedures [2604.26311].

Taken together, these characteristics make DreamProver a neural-symbolic theorem-proving system whose distinctive contribution is cumulative knowledge formation. Its central claim is not merely that LLMs can prove more theorems when given additional context, but that a prover can iteratively discover, validate, compress, and retain a compact body of reusable formal knowledge that materially improves generalization across related theorems [2604.26311].

Source: https://www.emergentmind.com/topics/dreamprover