--- title: 'PSV-Verus: Verified Self-Play Code Synthesis' url: https://www.emergentmind.com/topics/psv-verus type: topic --- # PSV-Verus: Verified Self-Play Code Synthesis PSV-Verus refers to a self-play training algorithm for formally verified code generation, introduced in "Propose, Solve, Verify: Self-Play Through Formal Verification" [2512.18160]. PSV-Verus leverages formal verification—specifically the Verus system for Rust programs—to train large language models (LLMs) on program synthesis tasks in the absence of human-written data. The core cycle alternates between generating new specifications (proposing), synthesizing programs (solving), and filtering via formal correctness (verifying), with difficulty-aware adaptation at every stage. ## 1. The Propose, Solve, Verify (PSV) Framework PSV-Verus employs two neural modules: a "proposer" $P_{\phi_t}$ responsible for generating synthetic formal specifications, and a "solver" $S_{\theta_t}$ trained to synthesize Rust+Verus proofs meeting these specs. A sound formal verifier $v(x, y) \in \{0, 1\}$ determines if candidate program $y$ is provably correct with respect to input specification $x$. The self-play protocol operates as follows: - From a seed set $X_0$ of specs, the solver produces $k_{\mathrm{trn}}$ solutions for each $x \in X_t$. - Solutions are formally verified; only $(x, y)$ pairs passing $v(x, y)$ are retained. - The solver is fine-tuned via rejection sampling on verified data. - The proposer is conditioned on both new verified specs and their pass rates to propose more challenging or diverse problems. - The combined set of specs expands for the next iteration, closing the learning loop. This self-play cycle is repeated for $T$ iterations, with the curriculum dynamically adapting as the solver improves. ## 2. Formal Verification as Supervision Verus provides SMT-backed formal verification. By design, its verifier is sound: $v(x, y) = 1$ implies $y$ is provably correct for all permissible inputs of $x$ within the Verus logic. This contrasts sharply with test-suite–based feedback, which is vulnerable to reward hacking and incomplete behavioral coverage. In PSV-Verus, only programs passing formal verification are used for further training, guaranteeing that the learned model only imitates verified-correct construction strategies. ## 3. Difficulty-Aware Proposal and Curriculum PSV-Verus employs difficulty-adaptive curriculum learning. Specifications $x_i$ are bucketed into four difficulty classes based on pass rate $r_{i,t}$: Easy, Medium, Hard, Impossible, using fixed thresholds $\tau_E$ and $\tau_M$: \[ \text{diff}(x_i, t)= \begin{cases} \text{Easy} & r_{i,t} \geq \tau_E \\ \text{Medium} & \tau_M \leq r_{i,t} < \tau_E \\ \text{Hard} & 0 < r_{i,t} < \tau_M \\ \text{Impossible} & r_{i,t} = 0 \end{cases} \] The proposer conditions on a uniform sample of difficulty buckets when generating new specs, ensuring that the solver is exposed to a spectrum of tractable and challenging problems. This explicit difficulty balancing, paired with dynamic updates as pass rates change, creates an evolving curriculum that closely follows solver capabilities. ## 4. Expert Iteration via Rejection Fine-tuning Solver training adopts a form of expert iteration or offline RL with binary reward, termed "rejection fine-tuning." Letting $D_t^*$ denote the set of formally verified $(x, y)$ pairs at iteration $t$: \[ D_t^* = \{(x_i, y^j_{i,t}) \mid v(x_i, y^j_{i,t})=1 \} \] The solver is trained using cross-entropy loss on this data, updating parameters $\theta$ via \[ \mathcal L_{\mathrm{solver}}(\theta) = -\frac{1}{|D_t^*|} \sum_{(x, y) \in D_t^*} \sum_{k=1}^{|y|} \log p_\theta(y[k] \mid x, y_{