---
title: 'CertiCoq: Verified Compiler Framework'
url: https://www.emergentmind.com/topics/certicoq
type: topic
---

# CertiCoq: Verified Compiler Framework

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 [2602.20082].

## 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 [2602.20082].

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 [2602.20082].

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 [2602.20082]. 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 [2602.20082].

ANF conversion is specified relationally as
$$
\Gamma;\Delta;\Phi \vdash_S e \rightsquigarrow (C,r,S'),
$$
where $S$ is a supply of fresh names, $\Gamma$ maps de Bruijn indices to fresh variable names, $\Delta$ and $\Phi$ track intermediate invariants, $e$ is the source term, and $(C,r,S')$ consists of a one-hole context $C$, a result variable $r$, and an updated name supply $S'$ [2602.20082].

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

- **Var rule**: if $\Gamma[n]=y$, then $\Gamma;\Delta;\Phi \vdash_S n \rightsquigarrow (\cdot,y,S)$.
- **Lam rule**: if $x_1,f \notin S$ and $\Gamma;x_1::\Gamma;\Delta;\Phi \vdash_{S\setminus\{x_1,f\}} e \rightsquigarrow (C_1,r_1,S')$, then
  $$
  \Gamma;\Delta;\Phi \vdash_S \lambda.e \rightsquigarrow (\mathrm{fun}\ f\ x_1\ \{C_1[\mathrm{ret}\ r_1]\}\cdot, f, S').
  $$
- **App rule**: if $\Gamma;\Delta;\Phi \vdash_{S_1} e_1 \rightsquigarrow (C_1,x_1,S_2)$, $\Gamma;\Delta;\Phi \vdash_{S_2} e_2 \rightsquigarrow (C_2,x_2,S_3)$, and $r \in S_3$, then
  $$
  \Gamma;\Delta;\Phi \vdash_{S_1} e_1\,e_2 \rightsquigarrow (C_1 \circ C_2\ \mathrm{let}\ r \leftarrow x_1\ x_2\cdot, r, S_3\setminus\{r\}).
  $$

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 [2602.20082].

## 3. Semantic preservation theorem for ANF

The main correctness result is stated using logical relations between source and target environments, values, and configurations. Writing $(\overline v,e)\Downarrow v$ for source evaluation, $\sigma[e]\Downarrow r$ for corresponding target evaluation, $\mathit{anf\_val\_rel}(v,v')$ for the value relation, $\mathit{anf\_env\_rel}(\overline v,\sigma)$ for the environment relation, and $E_k^i((\sigma_1,e_1),(\sigma_2,e_2))$ for the $i$-step-indexed logical relation on configurations, the theorem is presented as follows [2602.20082]:
$$
\textbf{Theorem (ANF Correctness).}
\quad
\forall\,\overline v,e,v.\;(\overline v,e)\!\Downarrow\!v
\;\to\;\bigl(\exists\,C,r,S'.\;\Gamma;\Delta;\Phi\vdash_S e\rightsquigarrow(C,r,S')\bigr)
\;\to\;\forall\,\sigma,v'.\;
\mathit{anf\_env\_rel}(\overline v,\sigma)\,\wedge\,\mathit{anf\_val\_rel}(v,v')
\;\longrightarrow
\;\forall\,i.\;
E^i\bigl((\sigma[x\mapsto v'],e_k),(\sigma,C[e_k])\bigr)\,.
$$

A central feature of the theorem is the universal continuation $e_k$, 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 $v$, then the ANF-converted program, in any target context, also terminates to a $v'$ related to $v$ [2602.20082].

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 [2602.20082].

| File | Lines |
|---|---:|
| Main simulation (“semantic preservation”) | 4,755 |
| $\alpha$-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 $V_k$, $R_k$, and $E_k$; 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 [2602.20082].

A representative application case is given in LaTeX. From an evaluation derivation $(\overline v,e_1e_2)\Downarrow v_2$ with subderivations $(\overline v,e_1)\Downarrow v_1$ and $(\overline v+v_1,e_2)\Downarrow v_2$, and an ANF derivation $\Gamma;\Delta;\Phi \vdash_S e_1e_2 \rightsquigarrow (C,r,S')$, the two induction hypotheses yield relations
$$
E^i\bigl((\sigma[x\mapsto v'],C_2[e_k]),(\sigma,C_1[C_2[e_k]])\bigr)
$$
and
$$
E^i\bigl((\sigma[x\mapsto v'],e_k),(\sigma,C_2[e_k])\bigr),
$$
from which transitivity gives
$$
E^{2i}\bigl((\sigma[x\mapsto v'],e_k),(\sigma,C_1[C_2[e_k]])\bigr).
$$
This exemplifies the way administrative structure is absorbed into the simulation argument rather than treated by backwards reasoning [2602.20082].

The proofs of the $\alpha$-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 [2602.20082]. 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 $\alpha$-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 [2602.20082].

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 [2602.20082]. 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 [2602.20082]. 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 $\ge$ 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 [2602.20082].

## 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 [2602.20082].

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 [2602.20082]. 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 [2602.20082].

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.

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