Code-as-Proof Verifiers

• Code-as-Proof Verifiers are systems where executable code acts as a formal certificate of correctness, merging implementation and proof.
• They employ methodologies like proof-producing verification, certifying computation, LLM-assisted proof agents, and algebraic encoding to generate verifiable proofs.
• These verifiers support robust applications from blockchain security to DNN verification by minimizing the trusted base and enforcing rigorous checks.

A code-as-proof verifier is a system that interprets code, potentially in concert with annotated specifications or proof artifacts, as an executable witness of correctness, which can be checked, validated, or certified by independent means—even across platforms, domains, and representation levels. Such verifiers blur the traditional distinction between code and proof: the code—enriched, instrumented, or accompanied by auxiliary artifacts—serves not only as an implementation but also as a formal certificate that can be subjected to rigorous, mechanized verification according to precise logical or semantic criteria (Tu et al., 21 Nov 2025, Furia et al., 2015, Duc et al., 11 Oct 2025, Asperti, 2017, Lindner et al., 2023, Avigad et al., 25 Jan 2025, Desmartin et al., 2024, Dupressoir et al., 2013, Alkassar et al., 2013, Avigad et al., 2021, Grov, 2014, Venkatkrishna et al., 17 Jan 2026).

1. Core Paradigms of Code-as-Proof Verification

The field encompasses several distinct but interlocking paradigms, all unified by the principle that executable code—or a closely related artifact—serves as the medium and record of proof:

• Proof-Producing Program Verification: The verifier constructs or extracts a proof object from code (e.g., via symbolic execution, type-based extraction, or SMT discharge), which is externally validated by a small, well-audited checker. This pattern is evident in interactive theorem provers like Coq, Lean, or HOL4, where proofs are represented as code (proof terms, scripts) for kernel validation (Tu et al., 21 Nov 2025, Asperti, 2017, Lindner et al., 2023, Avigad et al., 2021, Avigad et al., 25 Jan 2025).
• Certifying Computation: Algorithms produce, along with their output, auxiliary witnesses (certificates), which are checked by lightweight programs verified to enforce the correspondence between outputs and claimed properties (Alkassar et al., 2013).
• Proof-Carrying Code and Certificate-Driven Security: The code is accompanied by structured certificates (for safety, integrity, cryptographic security) that witness key properties; these are validated directly against the code or its actions (Dupressoir et al., 2013).
• LLM-Aided Code-Driven Proof Agents: LLMs drive interactive or autonomous proof search/construction, with the full proof certified by an independent formal system (e.g., Lean, Coq) (Tu et al., 21 Nov 2025, Duc et al., 11 Oct 2025).
• Algebraic and Cryptographic Proof-of-Execution: Code execution is algebraically encoded (e.g., for Cairo or STARKs in blockchain), and the trace of computation functions itself as a (machine-checkable) proof of execution (Avigad et al., 2021, Avigad et al., 25 Jan 2025).

The following table organizes several core technical implementations:

Paradigm	Primary Artifact	Checker/Validator
Proof-producing ITP	Proof terms / scripts	Trusted kernel
Certifying computation	Witness and checker code	Verified checker (VCC/Isabelle)
Algebraic encoding	Execution trace/algebra	Proof assistant (Lean)
LLM code-as-proof agent	Tactic scripts	Theorem prover (Coq)
DNN proof certification	DNN proof trees	Certified checker (Imandra)

2. Logical and Formal Foundations

Code-as-proof verifiers instantiate foundational paradigms from formal logic and program verification:

• Dependent Type Theory: Interactive theorem provers (ITPs) such as Coq and Lean internalize the Curry–Howard correspondence, treating proofs as typed functional programs. Proof terms are constructed by tactics or scripts and validated by a small kernel implementing the inference/tactic system (Asperti, 2017, Tu et al., 21 Nov 2025).
• Hoare Logic and Total Correctness: For code with Hoare-style contracts, verification conditions (VCs) generated from code annotations are discharged via SMT solvers or further checked as explicit certificates. This approach underpins systems like AutoProof (Furia et al., 2015), DTacs (Grov, 2014), and certifying checkers (Alkassar et al., 2013).
• Algebraic Constraints: In algebraic proof-of-execution (e.g., Cairo/STARK), programs are encoded as low-degree polynomial constraints over field elements, and a trace table (code-derived) constitutes the proof that all transitions and invariants were correctly enforced (Avigad et al., 2021, Avigad et al., 25 Jan 2025).
• Program Extraction and Reflection: ITPs support extracting total, correct-by-construction programs from constructive proofs, reflective code, or type-checked proof artifacts (Asperti, 2017).

Formal validation is governed by the small trusted kernel or proof checker: only code proofs that are accepted by the checker are trusted, independent of external heuristics or tactic search.

3. Architectures and Algorithms

Agentic/Learning-Driven Loop (AutoRocq, LLMs)

AutoRocq exemplifies an agentic architecture:

• A context-aware tactic generator (LLM) proposes proof steps based on the live proof state and retrieved context.
• A proof-tree interpreter maintains partial proof trees with subgoals as nodes and tactics as edges.
• A feedback handler parses error messages, prompting the agent to repair or issue context queries as needed.
• Proof construction proceeds in an iterative refinement loop. The agent alternates between tactic proposals and context queries, informed by tactic failure patterns and tree shape. Successful proof scripts are validated by the Coq kernel (Tu et al., 21 Nov 2025).

Code + Witness Workflow (Certifying Computation)

Certifying algorithm frameworks separate certificate generation from checking:

• The main code produces an output plus a witness.
• A verified checker validates the witness (e.g., ensuring it satisfies invariants, equations, or properties).
• High-level properties are proved about the witness in a theorem prover, which is connected (via axiomatic correspondence) to the code-level checker (Alkassar et al., 2013).

Proof-Producing Symbolic Execution

Proof-producing symbolic execution constructs a progress structure corresponding to all symbolic execution paths:

• Symbolic states and path conditions are propagated according to core soundness-preserving rules (e.g., symbstep, case, infeasible, transfer, sequence).
• ML-driven engines in HOL4 or similar systems build a proof tree for the code, representing the full symbolic execution as a certificate (Lindner et al., 2023).

Algebraic Encodings and Blockchain Verification

Cairo/STARK-style systems encode execution traces as field-valued matrix tables with polynomial constraints enforcing control flow, memory, and operation semantics. Proof-producing compilers (e.g., CairoZero) generate Lean artifacts for each code path, with correctness mechanized directly over the field-level execution (Avigad et al., 2021, Avigad et al., 25 Jan 2025).

4. Applications and Empirical Evaluation

• Program Verification (General/Domain-Specific): AutoRocq achieves state-of-the-art in program verification benchmarks such as CoqGym, SV-COMP, and Linux kernel modules, automating proof search for low-level C and mathematical code within the Coq ecosystem (Tu et al., 21 Nov 2025).
• Mathematical Theorem Proving (LLM as Prover/Verifier): Protocols utilizing LLMs to propose and revise proofs—validated in Lean with a final human schema check—demonstrate resolution of advanced IMO and conjectural problems (Duc et al., 11 Oct 2025).
• Deep Neural Network (DNN) Verification: Certified checkers like Imarabou provide proof-carrying verification for DNNs by recasting proof trees in a functional logic setting, with exact arithmetic eliminating floating-point errors (Desmartin et al., 2024).
• Cryptographic Protocol Security: Annotated C code and ghost state embedding in verifiers like VCC allow executable code to serve as the certificate for security properties under symbolic cryptography models (Dupressoir et al., 2013).
• Blockchain and Zero-Knowledge Proofs: Algebraic AIR representations and on-chain verification protocols turn compiled code into cryptographically certified proofs of execution, validated both via interactive proof systems and formal mechanization (Avigad et al., 2021, Avigad et al., 25 Jan 2025).
• Execution-Time/Resource Analysis: Symbolic execution frameworks yield machine-verified invariants and bounds for embedded binaries, e.g., ARM Cortex-M0 timing guarantees (Lindner et al., 2023).

Empirical metrics routinely evaluate:

• Unique and total proof obligations closed.
• Verification overhead and cost (wall time, API calls).
• Comparative ablations (context-search, feedback repair, proof-tree awareness).
• Scalability to large certificates and complex code bases.

5. Soundness, Limitations, and Trust Model

Code-as-proof verifiers adhere to stringent trust minimization:

• Minimization of the trusted computing base to kernel-level checkers (typed OCaml/C core, Lean/Coq kernel, or simple functional proof checkers).
• Artifact independence: the proof (certificate, execution trace, proof script) fully determines acceptance; the code/agent that generated it does not need to be trusted (only the checker).
• Robustness against overfitting, hallucination, and incomplete search through explicit witness validation and feedback.
• Limitations include LLM cost, latency, incomplete automation for loop invariants or full program synthesis, human-in-the-loop conversion steps (e.g., Lean script generation), and fragility if program layout or code extraction is perturbed (Tu et al., 21 Nov 2025, Duc et al., 11 Oct 2025).
• Extensions to memory safety, concurrency, and unverified code paths remain active research areas.

6. Trends, Open Challenges, and Future Directions

• Integration with LLMs: Expanding the automation frontier via agentic proof search (AutoRocq) and LLM-driven proof proposal/validation workflows, moving toward closed-loop generate-validate cycles (Tu et al., 21 Nov 2025, Duc et al., 11 Oct 2025, Venkatkrishna et al., 17 Jan 2026).
• Cross-Domain Certificates: Approaches in neural network certification, cryptographic protocol analysis, and blockchain proof-of-execution now routinely employ code-as-proof artifacts validated by foundational checkers (Avigad et al., 2021, Desmartin et al., 2024, Avigad et al., 25 Jan 2025, Dupressoir et al., 2013).
• Design of Usable Workflows: Striking a balance between user automation, proof reuse (history-driven search), feedback loop design, and legibility of certificates (both for experts and non-experts) remains central (Furia et al., 2015, Tu et al., 21 Nov 2025).
• Meta-verification and Trust: Efforts to minimize the size and complexity of trusted checkers, to formalize proof-producing algorithms (lifter correctness, symbolic semantics soundness), and to integrate end-to-end mechanization across heterogeneous artifacts (codes, algebraic traces, certificates) continue to evolve (Lindner et al., 2023, Avigad et al., 2021, Alkassar et al., 2013).
• Handling of Adversarial and Out-of-Distribution Scenarios: Empirical scaling laws demonstrate the importance of negative sample inclusion, on-policy RL updates, and chain-of-thought traces for maintaining robustness against domain shift and adversarial contexts in LLM verifier systems (Venkatkrishna et al., 17 Jan 2026).

Modern code-as-proof verifiers serve as a foundation for trusted, scalable, and composable verification pipelines—transforming programs and certificates into machine-checkable witnesses of correctness, security, and functional soundness across diverse application domains.