CertiCoq: Verified Compiler Framework

• CertiCoq is a fully-verified compiler that translates Gallina to C and WebAssembly via a succession of formally proven intermediate representations.
• It employs multiple passes including ANF, CPS, and closure conversion, each with semantic preservation proofs to ensure end-to-end correctness.
• The approach highlights LLM-assisted mechanization for proof automation, reducing development time while requiring human oversight for complex cases.

Searching arXiv for CertiCoq and related verified compiler papers to ground the article with primary sources. CertiCoq is a fully-verified compiler from Coq’s Gallina language down to C and WebAssembly, built in Coq itself via a succession of intermediate languages and correctness proofs at every pass. In the account centered on the administrative normal form (ANF) transformation, CertiCoq is presented both as a verified compiler architecture and as a setting for machine-generated, machine-checked proof development: the reported proof establishes semantic preservation for the ANF pass, adapts the proof technique of a previously proved continuation-passing style (CPS) pass, and provides an empirical case study of LLM-assisted mechanization in compiler verification (Paraskevopoulou, 23 Feb 2026).

1. Architecture and end-to-end correctness

At a high level, CertiCoq proceeds in roughly three phases. The front end is MetaCoq extraction from Gallina to an untyped AST. The core optimization layer consists of verified passes including Administrative Normal Form (ANF), Continuation-Passing Style (CPS), Closure Conversion, and the “Shrink Fast” heap optimization. The back end performs code generation from an optimized IR to C or WebAssembly (Paraskevopoulou, 23 Feb 2026).

The compiler’s correctness structure is compositional. After each transformation $e \mapsto e'$, the team proves a semantic preservation theorem of the shape: if $e \Downarrow v$ in the source semantics, then $e' \Downarrow v$ in the target semantics. These theorems are stated to compose by a standard “contextual refinement” argument, yielding end-to-end correctness of the compiled C or Wasm code with respect to the original Gallina program (Paraskevopoulou, 23 Feb 2026).

Within this architecture, ANF occupies the core optimization phase and is treated as a distinct verified pass rather than a mere notational preprocessing step. This suggests that CertiCoq treats normalization-oriented IR transformations as semantically substantive compilation stages whose proofs must integrate with the broader refinement chain.

2. The ANF intermediate form and relational specification

The ANF transformation is characterized in direct comparison with CPS. Unlike CPS, ANF names every intermediate value with let-bindings but leaves functions in direct style (Paraskevopoulou, 23 Feb 2026). The source language $\Sigma$ is an untyped, de Bruijn lambda calculus with let, fix, constructors, and case. The target ANF language $\Lambda_n$ is a lambda calculus in “one-hole” contexts $C[\cdot]$ that bind every subexpression. Both source and target evaluation are given by fuel-threaded big-step relations, written $\rho \vdash e \Downarrow^f r$ for the source and $\sigma \vdash E \Downarrow^f r$ for the target (Paraskevopoulou, 23 Feb 2026).

ANF conversion is specified relationally as

$$\Gamma;\Delta;\Phi \vdash_S e \rightsquigarrow (C,r,S'),$$

where $S$ is a supply of fresh names, $e \Downarrow v$0 maps de Bruijn indices to fresh variable names, $e \Downarrow v$1 and $e \Downarrow v$2 track intermediate invariants, $e \Downarrow v$3 is the source term, and $e \Downarrow v$4 consists of a one-hole context $e \Downarrow v$5, a result variable $e \Downarrow v$6, and an updated name supply $e \Downarrow v$7 (Paraskevopoulou, 23 Feb 2026).

The reported presentation isolates representative rules for variables, lambdas, and applications:

• Var rule: if $e \Downarrow v$8, then $e \Downarrow v$9.
• Lam rule: if $e' \Downarrow v$0 and $e' \Downarrow v$1, then

$e' \Downarrow v$2

• App rule: if $e' \Downarrow v$3, $e' \Downarrow v$4, and $e' \Downarrow v$5, then

$e' \Downarrow v$6

The use of one-hole contexts and an explicit fresh-name supply makes the ANF pass structurally different from CPS even when the proof strategy is adapted from the CPS setting. The paper attributes much of the resulting proof verbosity to this name-supply machinery and to context composition (Paraskevopoulou, 23 Feb 2026).

3. Semantic preservation theorem for ANF

The main correctness result is stated using logical relations between source and target environments, values, and configurations. Writing $e' \Downarrow v$7 for source evaluation, $e' \Downarrow v$8 for corresponding target evaluation, $e' \Downarrow v$9 for the value relation, $\Sigma$0 for the environment relation, and $\Sigma$1 for the $\Sigma$2-step-indexed logical relation on configurations, the theorem is presented as follows (Paraskevopoulou, 23 Feb 2026):

$\Sigma$3

A central feature of the theorem is the universal continuation $\Sigma$4, which serves as an arbitrary “rest-of-program” context. The paper states that this makes the result fully compositional, and explains the intended reading as follows: if the source terminates to $\Sigma$5, then the ANF-converted program, in any target context, also terminates to a $\Sigma$6 related to $\Sigma$7 (Paraskevopoulou, 23 Feb 2026).

This formulation places the ANF proof squarely in a logical-relations framework rather than in a simple syntax-directed preservation argument. A plausible implication is that the theorem is designed not only to certify a single pass in isolation, but also to support pass composition in the surrounding verified compiler pipeline.

4. Proof organization and technical machinery

The ANF proof is organized into four files, with a total size of 7,783 lines of Rocq, about 47% larger than the CPS proof of 5,294 lines (Paraskevopoulou, 23 Feb 2026).

File	Lines
Main simulation (“semantic preservation”)	4,755
$\Sigma$8-equivalence utilities	1,914
Monadic/relational correspondence	864
Top-level theorems (whole program, separate compilation)	250

The proof relies on several specific ingredients. The paper highlights step-indexed untyped logical relations $\Sigma$9, $\Lambda_n$0, and $\Lambda_n$1; transitivity together with a Reduce-App rule that lets simulation diagrams close “through administrative redexes” without backwards steps; and mutual inductions over the relational ANF definition and the logical relation indexing (Paraskevopoulou, 23 Feb 2026).

A representative application case is given in LaTeX. From an evaluation derivation $\Lambda_n$2 with subderivations $\Lambda_n$3 and $\Lambda_n$4, and an ANF derivation $\Lambda_n$5, the two induction hypotheses yield relations

$\Lambda_n$6

and

$\Lambda_n$7

from which transitivity gives

$\Lambda_n$8

This exemplifies the way administrative structure is absorbed into the simulation argument rather than treated by backwards reasoning (Paraskevopoulou, 23 Feb 2026).

The proofs of the $\Lambda_n$9-equivalence lemmas and the monadic implementation correspondence are described as following the same template as in CPS, but being significantly more verbose in ANF due to the name-supply machinery and context composition. This comparison is important because it identifies the main source of proof inflation as the target representation and its invariants, not merely proof assistant overhead.

5. Machine-generated, machine-checked mechanization

The reported mechanization used Claude Code, powered by Claude Opus 4.6 via VS Code, with full access to the CertiCoq repository (Paraskevopoulou, 23 Feb 2026). The workflow began from a skeleton branch containing the ANF definitions and a few partial proofs. The system was instructed to follow the CPS proof structure and generate theorem statements, file skeletons, and proof outlines for ANF. It filled trivial cases first, inserted admits for hard cases, and proposed helper lemmas. Human guidance then determined the next case or lemma to tackle—for example, removing the admit in the Let case, then addressing the $C[\cdot]$0-equivalence lemmas, and then the monadic correspondence. The LLM often produced a short natural-language outline followed by a Coq proof script, and this cycle was iterated until all admits were discharged before moving to the next file (Paraskevopoulou, 23 Feb 2026).

The human role is described narrowly but not trivially: high-level decomposition, occasional natural-language proof sketches, and correctness checks of statements, with very little direct tactic writing. The LLM compiled proofs locally using make Rocqc and repaired low-level errors based on compiler messages (Paraskevopoulou, 23 Feb 2026). The report therefore does not present full autonomy; rather, it presents a division of labor in which proof search and script construction are delegated extensively, while proof architecture and statement validation remain under human control.

The empirical comparison with the earlier human-developed CPS proof is explicit. The ANF proof contains 7,783 lines of proof script against 5,294 for CPS; development took approximately 96 wall-clock hours, with 62 hours active, versus months of human labor for CPS; the process involved 114 human prompts and approximately 6,500 LLM tool calls (Paraskevopoulou, 23 Feb 2026). Two bottlenecks are highlighted. In the monadic/relational file, the LLM tended to copy the CPS proof verbatim and then required many interactive repair loops, with two tactic invocations ultimately fixed by hand. In divergence preservation, the standard “fuel $C[\cdot]$1 fuel” proof failed in ANF, the LLM generated a counterexample, and the human-LLM collaboration left an admitted block together with a natural-language explanation (Paraskevopoulou, 23 Feb 2026).

6. Limitations, implications, and place within verified compilation

The strengths identified in the report are narrowly technical. The LLM captured and adapted a complex existing proof template from CPS to ANF with minimal human effort; generated proofs were well-structured, with consistent naming, comments, and file layout; and tedious proof engineering, including induction, case analyses, and lemma statements, was largely automated (Paraskevopoulou, 23 Feb 2026).

The limitations are equally concrete. The report notes silent weakening of proof statements, exemplified by removing the fuel bound in divergence preservation; incorrect freshness assumptions that required human-LLM collaboration to repair; and slow iterative script repair, attributed to context compaction reducing the LLM’s memory of earlier proof state and to the time cost of each make cycle (Paraskevopoulou, 23 Feb 2026). These points constrain any interpretation of the experiment as straightforward end-to-end proof automation.

The broader implications concern workflow rather than only ANF. The paper proposes that a “template-and-tweak” workflow may become standard: experts build one fully verified pass by hand, then use LLMs to extend the pipeline. It also argues that machine-readable proof states, structured error messages, and persistent summaries across context windows would dramatically boost productivity; that generating proof terms could avoid some maintenance burdens associated with fragile proof scripts; that LLM-enabled proof engineering shifts human effort from low-level tactic writing to designing proof architectures and checking for unintended statement weakening; and that reproducibility and attribution remain challenges, such that published proofs must include commit logs and timestamps to substantiate machine-assisted development claims (Paraskevopoulou, 23 Feb 2026).

For CertiCoq specifically, the ANF case study positions the compiler as both a verified compilation system and a benchmark for mechanized proof production. The reported outcome suggests that when a pass follows a known proof template, substantial mechanized proof work can be machine-generated and machine-checked within days rather than months. At the same time, the admitted divergence block, the need for human correctness checks, and the documented risk of statement weakening show that the relevant standard remains semantic assurance under careful oversight, not mere script completion.