---
title: 'StepFun-Prover Preview: Interactive Formal Proofs'
url: https://www.emergentmind.com/topics/stepfun-prover-preview
type: topic
---
# StepFun-Prover Preview: Interactive Formal Proofs
StepFun-Prover Preview is a large language model for formal theorem proving that couples language-model generation with verifier-mediated interaction in Lean 4. It is built on pre-trained LLM variants with roughly 7B and 32B parameters, instruction-tuned for formal theorem proving, and organized around a tool-integrated reasoning loop in which the model alternates among free-form natural-language thinking, partial Lean 4 proof sketches, and real-time verifier feedback. On miniF2F-test, StepFun-Prover-Preview-32B attains $\mathrm{pass@1}=70.0\%$ with $N=32$ generated samples per query and a maximum context length of 20 K tokens, positioning the system as a minimal-sampling theorem prover rather than a purely text-only generator [2507.20199].
## 1. Agentic reasoning loop and interaction model
The central design of StepFun-Prover is an agentic, tool-integrated loop with three explicitly interleaved modalities: free-form natural-language “thinking,” partial Lean 4 proof sketches wrapped in `...` tags, and real-time Lean 4 verifier feedback wrapped in `...` tags. At test time, and likewise during reinforcement-learning rollouts, the model repeatedly decides whether to generate further reasoning, emit a new proof sketch, or terminate deliberation and output a final proof after a `` delimiter. When `` appears, the enclosed Lean 4 code is extracted, sent to a remote Lean 4-REPL server, and the resulting error or success messages are returned as `` feedback [2507.20199].
The resulting trajectory has the form
$$
[g_1\ \text{(text)} \circ s_1\ \text{(sketch)} \circ f_1\ \text{(feedback)} \circ \cdots \circ p\ \text{(final code)}],
$$
and functions simultaneously as chain of thought and as training signal. In this organization, verifier interaction is not an external post hoc filter; it is part of the model’s internal problem-solving trajectory. A plausible implication is that proof search is partially offloaded from independent resampling into within-trajectory correction driven by environment feedback.
## 2. End-to-end training pipeline
The training pipeline is described as a four-phase process that combines synthetic data construction, supervised fine-tuning, response-style harmonization, and tool-integrated reinforcement learning. The initial phase assembles a cold-start dataset from open sources and generated interaction traces; subsequent phases progressively teach Lean syntax, proof patterns, tool use, and correction of failed proof attempts [2507.20199].
| Phase | Main operations | Output |
|---|---|---|
| 1. Cold Start Data Synthesis | Collect Lean Workbook and STP; autoformalize via Kimina-Autoformalizer; filter low-quality or trivial statements; generate $\sim 8$ K multi-turn REPL trajectories with Claude Sonnet 4; extract single-turn Q–A pairs from Kimina-Prover-72B by stripping intermediate tactics | Initial dataset $\mathcal{D}_0$ |
| 2. Two-Stage Supervised Fine-Tuning | SFT on STP, then SFT on $\mathcal{D}_0$ for tool-integrated interactions | Model $M_0$ |
| 3. Response Fusion | Collect Kimina-Prover-72B failures; have $M_0$ correct them; SFT on resulting $\mathcal{D}_1$ | Model $M_1$ |
| 4. Tool-Integrated RL and Iterative RL–SFT | Initialize RL from $M_1$; after convergence, collect under-performing but correct-refined trajectories for another SFT round, then a final RL phase | Final model |
Two implementation details are especially consequential. First, the system performs an initial SFT stage on STP specifically to learn Lean syntax and proof patterns before introducing tool-integrated interaction data. Second, during SFT on tool-integrated data, REPL feedback tokens are masked out of the loss so that the model does not simply memorize environment outputs. This training choice preserves the role of the verifier as an external source of state information rather than a distribution to be imitated.
## 3. Reinforcement-learning formulation
StepFun-Prover adopts a policy-gradient procedure described as Gruppo RL with no KL-penalty, akin to PPO without KL, to refine a policy $\pi_\theta$ over a set $\mathcal{Q}$ of formal problems. For each prompt $q \in \mathcal{Q}$, the old policy $\pi_{\theta_{\text{old}}}$ samples $G$ proof trajectories $\{o_1,\ldots,o_G\}$, each containing reasoning, sketches, and REPL feedback. Reward is assigned only to the final Lean 4 proof after ``: $r_i = 1$ if the REPL accepts the proof and $r_i = 0$ otherwise. The group-based advantage is then normalized as
$$
A_i = \frac{r_i - \mu_r}{\sigma_r},
$$
where $\mu_r$ and $\sigma_r$ are the mean and standard deviation of the rewards within the group [2507.20199].
The GRPO objective uses a clipped-ratio formulation, described as encouraging exploration without exploding gradients. This is paired with a sparse binary terminal reward rather than intermediate dense reward shaping. A common misunderstanding would be to assume that every intermediate sketch is rewarded directly; the specified procedure instead evaluates only the final proof after the model terminates thinking. The role of intermediate verifier calls is therefore diagnostic and corrective within rollout, not directly supervisory at the reward level.
Minimal sampling is attributed to this architecture. Because the model can self-correct using real-time REPL feedback during each rollout, the number of independent proof attempts needed is reduced. In the reported configuration, StepFun-Prover-32B reaches $70\%$ pass@1 with only 32 samples per problem, whereas the comparison point in the description is “much larger models requiring thousands of samples” [2507.20199].
## 4. Benchmarking, pass@k estimation, and ablations
Evaluation is reported on miniF2F-test, corrected by Numina. With $N=32$ generated samples per query, pass@k is estimated from the number $s$ of successful samples among the $N$ trajectories as
$$
\mathrm{pass@k} \approx 1 - \frac{\binom{N-s}{k}}{\binom{N}{k}}.
$$
The reported results show StepFun-Prover-Preview-32B at $\mathrm{pass@1}=70.0\%$ with maximum context length 20 K tokens, surpassing Kimina-Prover-72B at $63.9\%$ [2507.20199].
| Model | Pass@1 |
|---|---|
| DeepSeek-671B | 61.9% |
| Kimina-72B | 63.9% |
| StepFun-7B | 64.2% |
| StepFun-32B | 70.0% |
The comparison is notable because the 7B variant already exceeds DeepSeek-671B in the reproduced table, and the 32B variant establishes the highest pass@1 among the listed systems. Performance is also reported to scale smoothly with generation length, increasing from $58.3\%$ at 4 096 tokens to $70.0\%$ at 20 480 tokens. This token-length trend indicates that the model continues to benefit from longer interaction horizons rather than saturating early.
Ablation results further isolate the contribution of the training regime. Removing tool-integrated RL or removing the iterative RL–SFT loop degrades pass@1 by 10–15%. This identifies the reinforcement-learning phase and the alternation between RL and SFT as structural components of the system rather than ancillary optimization stages.
## 5. Human-like proof construction and corrective behavior
StepFun-Prover is explicitly characterized as emulating several behaviors associated with expert Lean users. The first is **Proactive Diagnosis**: the model examines even non-error warnings and restructures proofs accordingly. The second is **Adaptive Timeouts**: if a subproof exceeds 60 s, the agent reorganizes tactics into simpler forms. The third is **Iterative Refinement**: each item of REPL feedback associated with a sketch informs the next reasoning step, producing a trial-and-error loop aligned with interactive theorem-proving practice [2507.20199].
A representative proof described in Appendix A begins with syntax errors and algebraic miscalculations surfaced through `` tags, after which the model adopts a high-level sum-of-squares strategy and then closes the final proof in one go. The significance of this example is methodological rather than anecdotal: it shows that the system is not merely generating tactic strings but altering high-level proof strategy in response to formal execution feedback. This suggests a proof-search process that mixes symbolic verification with flexible language-mediated replanning.
The system therefore differs from a static chain-of-thought model in two respects. Its intermediate reasoning is externally grounded by the Lean 4 environment, and its sketches are provisional objects meant to be revised. The phrase “Let’s Think and Verify Step by Step” is operationalized literally: thinking and verification are alternating components of one trajectory rather than separate stages.
## 6. Algebraic-verification substrate and trusted code base
StepFun-Prover is also presented as building directly on the algebraic-verification framework for Cairo execution traces formalized in “A verified algebraic representation of Cairo program execution” [2109.14534]. In that framework, Cairo’s execution model is defined over a small CPU with registers $\mathrm{pc}$, $\mathrm{ap}$, and $\mathrm{fp}$, memory modeled as a total function over a field, and a small-step relation `next_state` capturing execution semantics. The execution trace is arranged as a table of
$$
N = 16(T+1)\ \text{rows} \times 25\ \text{columns},
$$
with 23 raw trace columns and 2 interaction columns, and each column is interpreted as a univariate polynomial over an extension field [2109.14534].
Three classes of polynomial-identity constraints are then imposed: boundary constraints for initial and final register values, transition constraints encoding small-step semantics, and permutation and memory-consistency constraints that enforce read-only memory consistency via randomized checks. The Lean 3 formalization is organized around `cpu.lean`, which defines instruction decoding, `register_state`, `next_state`, and agreement theorems such as `next_fp_agrees`, and `constraints_autogen.lean`, which declares the trace columns and polynomial constraint families. Its capstone result is the theorem `final_correctness`, which yields an end-to-end correspondence between valid algebraic traces and genuine Cairo executions [2109.14534].
Within the described StepFun-Prover stack, the entire AIR—trace layout, selector columns, interaction rows, and polynomial constraints—is canonically extracted from `constraints_autogen.lean` into the prover’s trusted input, and the STARK prover and verifier consult those same polynomials. The stated trust roots are the Lean kernel, the STARK protocol, and the code extraction pipeline. In that formulation, verifier checks and formally proved semantics are aligned at the level of the exact constraints used in execution certification.
## 7. Position within automated theorem proving and stated future directions
The reported results are used to argue that tightly coupling LLM reasoning with formal verifiers via reinforcement learning can deliver both higher accuracy and far fewer samples than purely text-based chain-of-thought or search-based methods [2507.20199]. The key point is not only the absolute pass@1 value, but the combination of sparse terminal reward, interactive correction, and low sampling budget. StepFun-Prover is therefore framed as an end-to-end training framework for tool-integrated reasoning models, not merely as a benchmark-optimized Lean prover.
Several future directions are named explicitly. These include transferring the techniques to informal mathematics and other proof assistants, designing multi-agent systems for collaborative proof discovery, and incorporating richer metadata such as proof term analysis into the reward signal. The associated interpretation is direct: the model family is intended as a prototype for Math AI assistants and automated theorem provers that learn to self-reflect, self-correct, and self-direct tool use [2507.20199].
In this formulation, StepFun-Prover Preview occupies a specific technical niche. It combines instruction-tuned formal proving in Lean 4, verifier-mediated intermediate interaction, GRPO-style reinforcement learning, and iterative RL–SFT refinement, while also being situated within a broader verified-computation substrate linked to machine-checked algebraic representations. Its contribution is thus best understood as a synthesis of interactive proof engineering, reinforcement learning, and formally grounded execution feedback.
Source: https://www.emergentmind.com/topics/stepfun-prover-preview